User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 The intelligent tab order used when browser.tabs.selectOwnerOnClose is set to true seems to be broken. When clicking a link on a web page via middle click (CMD+click on a mac) or context menu (open link in new tab) and closing it again (close button/CMD+W) the tab isn't set to the originating one but to the tab next to the closed one. Contrary, if the specified link is just clicked with the left mouse button (and has target=_blank / unknown target set), closing the new tab DOES select the owner on close correctly. The problem seems to have surfaced with the update to 2.0.0.2. I've recreated this behavior on OS X 10.4.9 (PPC) with a new profile and all extensions disabled. Additionally, I've tried several web sites to see if it is affected by page content, but it seems like this isn't a site/source code-specific problem. Since I'm unable to test this one on Windows, I've set HW/OS to Mac/OS X. If Windows users can reproduce this bug, please edit the entry accordingly. Reproducible: Always Steps to Reproduce: 1. Open link in web page via CMD+click or "Open Link in New Tab" 2. When new tab appears, close it via CMD+W or the close button b) Do as in a) but open link with <a target> set to an unused name. Actual Results: a) On close, the tab next to (as in displayed tab order) the recently closed tab is selected. b) On close, the tab from which the link originated is selected. Expected Results: In a) the active tab should've been set to the parent tab.

This is kind of working as designed, see bug 345033, bug 344508 and bug 422088: from http://wiki.mozilla.org/Link_Targeting#Moving_Focus_after_Closing_Tabs "One potential way of detecting this would be to give focus to the previously selected tab when: * a new tab has opened with focus * focus does not move from that tab before it is closed" The idea was, AFAICS, that you can open multiple tabs in background, in which case the "selecting the parent tab" behavior would be annoying. However, in case only one tab is opened in background, I think it makes more sense to use that tab-activation logic, as when opening a link in a foreground tab. I couldn't find a bug where this suggestion was explicitly wontfixed, so confirming.

So the use-case that was being solved by the tab-ownership code was this (from the same wiki page): "some small-sample usability studies have shown that users frequently open tabs to accomplish some intermediate step in their task (ie: read a definition) and once the tab is closed they wish to be returned to the previously selected tab to continue with their main task." From my own experience I can say that the tab for this intermediate step is often opened in background by power tab users, because: 1) you don't want to sit there waiting for the intermediate page to load 2) it's actually easier to reliably open a page in background (middle-click) than in foreground So I read page A, middle-click a link on it, when I see that the page is loaded, I switch to it, read it and close it to return to the previous page. Google Chrome selects the parent tab in this case. (Although its tab-ownership logic differs from Firefox in other cases too.)

If browser.tabs.loadInBackground is false, the new tab isn't opened in the foreground and so no ownership relationship is set, per comment 1. If it's true (not the default), this works as intended.