Search and Top Navigation
#7204 closed bug (fixed)
Opened March 27, 2011 04:38PM UTC
Closed May 17, 2011 08:23PM UTC
Tabs: Programmatically loading a tab shouldn't cancel active ajax requests
| Reported by: | Azhrei | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.9.0 |
| Component: | ui.tabs | Version: | 1.8.10 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I tried to implement an ajax-heavy page using Tabs and found multiple issues where some added details in the documentation would've been very helpful:
tabs("add", ...)will automatically load the page referenced by the URL parameter if it is the first tab being added.
tabs("load", ...)will cancel any pending ajax requests by Tabs before queuing up the new one.
I believe the second one might be a bug. I would like to load my page, dynamically determine which tabs I need and call **add** (which will auto-load the first one), and then queue up **load** requests for the others tabs. Ideally, I'd like the other tabs to load only upon completion of the first one.
Currently, in order to accomplish this here's what I do: call **add** and create all tabs with a URL of # (so nothing auto-loads), call **url** and change the URL for the first tab, call **load** and start it loading. In the **tabsload** event I set a timer to go off that does the same thing again for the next tab. I have to use a timer since the **tabsload** event is fired while handling the current ajax request and a direct attempt to call **load** for the next tab seems to cancel the current one!
This is the case with 1.8.10 and I've looked at the code for 1.8.11 and still see calls to .abort() inside **load** -- and a call to .load() inside **add** -- so I don't think anything has changed in this regard in the latest version.
Attachments (0)
Change History (4)
Changed March 28, 2011 08:23PM UTC by comment:1
| status: | new → open |
|---|
Changed March 28, 2011 08:39PM UTC by comment:2
Replying to [comment:1 gnarf]:
You want something along the lines of: "The page referenced by the URL will not be loaded until the tab is selected (which may be immediately if no other tabs exist)" on the docs for the add method?
Yes, that would work. Note that add() actually calls load(). I can't see how an ajax request could already be active when add() is called, but I just wanted to point that out.
I think that the "load" method calling.abort()could actually be considered a bug... The behavior probably exists for the case when someone clicks quickly between two tabs to cancel the 'useless' request before sending a new one, but I think that manual calls to "load" should just start a request for that content, and perhaps even in the double navigation cancel it may be worth it to just load the content anyway - you already made the request...
But again, it would be the select() method that cancels existing requests, not load(). I can completely understand the thinking behind having an existing request canceled, I just think it belongs in select() instead of in load(). Note that moving the call to abort() from load() to select() means your existing scenario stays the same, but programmatic uses of load() allow for multiple simultaneous requests...
Changed May 17, 2011 08:21PM UTC by comment:3
| summary: | Documentation request for Tabs → Tabs: Programmatically loading a tab shouldn't cancel active ajax requests |
|---|
I'm changing this ticket to be a bug about the load behavior.
Changed May 17, 2011 08:23PM UTC by comment:4
| resolution: | → fixed |
|---|---|
| status: | open → closed |
Tabs: Don't cancel existing ajax requests when programmatically loading a tab. Fixes #7204 - Tabs: Programmatically loading a tab shouldn't cancel active ajax requests.
Changeset: 03939fc8c14cd93f081c3195cdcdef6c56a6fccf
You want something along the lines of: "The page referenced by the URL will not be loaded until the tab is selected (which may be immediately if no other tabs exist)" on the docs for the add method?
I think that the "load" method calling
could actually be considered a bug...The behavior probably exists for the case when someone clicks quickly between two tabs to cancel the 'useless' request before sending a new one, but I think that manual calls to "load" should just start a request for that content, and perhaps even in the double navigation cancel it may be worth it to just load the content anyway - you already made the request...