Bug 172962 introduced single-window mode, which is a great convenience and represents the next logical step in tabbed browsing. However, it's not quite polished yet. Specifically, when a user has options set such that external applications that open links open them in new tabs, Firefox will steal focus from the original window before it has started loading the new tab. A step-by-step description might help: 1. Have the "external apps open in new tabs" pref set. 2. Open up Firefox with a a web page already displayed (e.g., Google). 3. Click on a link in your email reader of choice. 4. Firefox will steal focus, but Google will still be displayed. 5. A very small fraction of a second later, the new tab will open and the link will start loading. It's the "Google will still be displayed" and "new tab will open" parts that are the bug, and it can be rather disconcerting to see Google, just barely understand what you're seeing, and then have it disappear on you as the new link loads. Here's what should happen: 1. Have the "external apps open in new tabs" pref set. 2. Open up Firefox with a a web page already displayed (e.g., Google). 3. Click on a link in your email reader of choice. 4. Firefox will open the new tab and start loading the link. 5. Once the tab has started loading and is active, Firefox will steal focus. Basically, Firefox should start loading an external link in a new tab and should select the tab *before* stealing focus. As this was just recently implemented and is therefore relatively fresh in danm's mind, I'm going to request blocking-aviary1.0 for this. Hopefully it's just an issue of switching the order of code execution around in app logic.

The fix isn't so simple as Jeff hopes. It's a function of when the browser window is activated, and that's a platform-dependent issue involving focus and widgetry and the application/OS interface. Jeff, I know you're using Windows since this capability was activated in the other platforms just today. We don't really know yet how the other platforms behave, so I'm restricting this bug's reported platform until we know more. This bug, which concerns itself over when the window should be activated, is a subset of bug 263553, which concerns itself over whether the window can avoid being activated at all. Also of note, the third patch in bug 255123 fixes this polish problem on Windows. Other platforms; we don't know. I'm thinking this bug isn't half the bug that many a blocking nomination has already been tossed out over. I'll let the Aviary team decide, but I say it's a quick minus. Note there is a Windows fix available in an unreviewed patch in another 1.0-minused bug. That bug is probably a good thing on its own merits. But you should start there if you want to consider +ing this bug.

If it's a bigger problem than logic reordering, foregt blocking-aviary1.0? then.

I am unable to reproduce this bug on Nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130212 Firefox/21.0). Please re-open if this is still an issue. Thanks!