User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Refer to bug 338348. The call BrowserNumberTabSelection(event, 8); does not select the ninth tab, but the last. This is, it's safe to say, a misfeature. (couldn't you use -1 if you need a sentinel value?) The current implementation has the disadvantage that people who actually want to be able to select the ninth tab (myself among them; I can indeed tell the ninth tab in a window from the eighth and tenth on sight) have to resort to some workaround. I've had to bind ctrl-9 to BrowserNumberTabSelection(event, 7); gBrowser.mTabContainer.advanceSelectedTab(1,true); Reproducible: Always

Do you want to submit a patch? There's some documentation at http://developer.mozilla.org/en/docs/Creating_a_patch and http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree if you're not familiar with the process.

This does more than what's actually needed... 1. If we want to optimize that function for external usage (which this bug seems to be about), I think it makes sense to make the event optional, because we don't really need it to select the nth tab. 2. Made the function a tabbrowser method. tabbrowser.xml is already huge, but not as huge and cluttered as browser.js.

Comment on attachment 328327 [details] [diff] [review] patch v1 >+ // aIndex == -1 selects the last tab, e.g. for Ctrl+9 >+ var newTab = aIndex < 0 ? >+ this.tabContainer.lastChild : >+ this.mTabs[aIndex]; What about further generalizing this into negative numbers just counting backwards (i.e. -2 meaning the second last tab, etc.)? > var newTab = this.mTabs[aIndex < 0 ? this.mTabs.length + aIndex : aIndex];

(In reply to comment #3) > What about further generalizing this into negative numbers just counting > backwards (i.e. -2 meaning the second last tab, etc.)? I thought about this but couldn't find a good use case. Doesn't hurt to add it, though. Btw, I don't think it makes sense to let the event propagate for Ctrl+8 if there happen to be only 7 tabs. The new patch changes this.

slightly less nested

It would be nice to have a test for this (just open a bunch of tabs, simulate the events, check that the correct tab is selected).

Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre, Ctrl+9 still selects the last tab when there are more than 9 tabs. Same thing happens on Win Vista. I am not sure if this is expected or not based on the comments from the reporter, but if Ctrl+9 is always supposed to take you to the last tab then I can confirm this.

Yes, that's expected, per bug 338348.

dev-doc-needed to document the new function |selectTabAtIndex|. It can be used to select "negative" tabs, i.e. 2 from the last or to just directly select a tab at any given index.

https://developer.mozilla.org/en/XUL/tabbrowser#m-selectTabAtIndex https://developer.mozilla.org/en/XUL/Method/selectTabAtIndex dev-doc-complete