Creating a new tab causes url to change

[aleemb]

This is causing all sort of issues on my end. The scenario is that I have a tab labelled "+" which if clicked adds a new tab:

$('#mytabs').tabs({ 'select' : this._tabClick });
...
_tabClick : function(event, ui) {
if (ui.tab.id == 'add') // user clicks "+" tab
{
	$('#mytabs').tabs('add', '#newtab', 'new tab', ui.index);
}
}

The last statement which adds the new tab is triggering the bug. The URL changes to ​http://myurl.com/#add where add is the href for the "+" tab. This doesn't happen in rc5 or rc6 but only in the code that's in the trunk.

To mitigate I have had to change the last line to:

setTimeout(function(){$('#mytabs').tabs('add', '#newtab', 'new tab', ui.index); }, 1);

Which doesn't cause the url to change.

There is another issue with the URL being changed. Since the browser already points to ​http://myurl.com/#add clicking the "+" tab doesn't work (doesn't trigger the select handler _tabClick).

There is yet another issue here in that in the _tabClick handler function I immediately wanted to select the just added tab for which I was using:

$('#mytabs').find('a[href=#newtab]').click();

that didn't work (in rc5, rc6 or trunk) but I suspected a race condition so tried the following which worked:

setTimeout(function(){$('#mytabs').find('a[href=#newtab]').click();}, 1);

[klaus.hartl]

IE only?

[aleemb]

Both IE7 and FF3 have the issue.

[Jörn Zaefferer]

Have you tried adding "return false" in the select-handler?

[aleemb]

Missed that one... it's a better work around. Using that instead now instead of setTimeout. (had earlier tried stopPropagation and stopImmediatePropagation both of which didn't work).

[klaus.hartl]

I couldn't duplicate the first error. Regarding selecting a just added tab, see also ​http://docs.jquery.com/UI/Tabs#...immediately_select_a_just_added_tab

The url changing is duplicate: #4134