263964 - Current tab briefly displays before new tab is opened with "open links from apps in new tabs" set

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Jeff Walden [:Waldo]]

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.

Comment 1

[Dan M]

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.

Comment 2

[Jeff Walden [:Waldo]]

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

Comment 3

[Mike Conley (:mconley) (:⚙️)]

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!