#4578 closed bug (fixed)
adding tab moves targeted panel
Reported by: | gpbmike | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.9.0 |
Component: | ui.tabs | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
using the 'add' method will move the targeted panel after the tabs ul.
creating tabs doesn't move any targeted panels, so i wouldn't expect adding a tab to move a panel either.
Change History (9)
comment:1 Changed 14 years ago by
Milestone: | TBD → 1.8 |
---|
comment:2 Changed 14 years ago by
comment:3 Changed 13 years ago by
I'd like to patch this bug but I'm unsure of what the correct behavior should be. The issue occurs when using a markup structure that doesn't match the default. If you add a new tab to the end of the list (which is the default behavior if you don't specify an index) specifying the id of a content div that is already in the DOM, it will be inserted after the UL containing the tabs. If you do the same, but specify an index that's not the end of the list, it will be inserted after an existing content element, which may or may not match the behavior of the first case.
Example: http://bryanrsmith.com/tabs.html
Note that when you insert a new tab anywhere other than the end of the list, it's added to #content-container, however, if you insert a new tab at the end of the list, it's appended to the ul's parent, which is not the correct location.
The offending code (from line 468 of jquery.ui.tabs.js)
// try to find an existing element before creating a new one var $panel = $('#' + id); if (!$panel.length) { $panel = $(o.panelTemplate).attr('id', id).data('destroy.tabs', true); } $panel.addClass('ui-tabs-panel ui-widget-content ui-corner-bottom ui-tabs-hide'); if (index >= this.lis.length) { $li.appendTo(this.list); $panel.appendTo(this.list[0].parentNode); // Bad: maybe this.list[0].parentNode is not where we're keeping our content elements } else { $li.insertBefore(this.lis[index]); $panel.insertBefore(this.panels[index]); // Correct, as long as there is at least 1 existing tab }
It seems to me that the correct behavior is to not try to re-insert the content div if it already exists in the DOM-- just leave it where it is. An alternative may be to add a parameter for a DOM element for the content div to be appended to. This would also allow the plugin to work consistently when adding a remote tab to an instance of tabs that currently has 0 tabs, in which case we have no way to know where the new tab should be inserted.
This is the only place in the tabs plugin I've found that causes problems when using a non-standard markup structure. Any thoughts on how to handle it?
comment:5 Changed 12 years ago by
I got bitten by this bug. It was very useful to know there was a simple workaround which is to supply a value for the index
parameter.
i.e.
Broken (due to missing index
parameter):
$('#tabs').tabs( "add" , '#portfolio-image-tab' , 'Portfolio Image');
Working (due to supplied index
parameter):
$('#tabs').tabs( "add" , '#portfolio-image-tab' , 'Portfolio Image', 2);
comment:6 Changed 12 years ago by
Status: | new → open |
---|
Taking a peek into this source makes me wonder if the $panel.appendTo()
call in that if couldn't use this.element
and see this bug disappear.. What is the "parentNode" functionality in there right now doing, basically selecting this.element
right??
comment:7 Changed 12 years ago by
Pull request for this fix is here: https://github.com/jquery/jquery-ui/pull/251 (closed)
comment:8 Changed 12 years ago by
new pull request for this fix here: https://github.com/jquery/jquery-ui/pull/274
comment:9 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | open → closed |
Tabs: When adding a new tab with an existing panel, don't move it. Fixes #4578 - adding tab moves targeted panel.
Changeset: 965cb7359ea704715839e3c171ae751d6a32dde9
Could you explain that a little more? Do you refer to the situation where you add a tab that targets a panel (e.g. div) that exists in the DOM already?