Firefox comes to front when opening link via external program.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux ppc; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120410132944

Steps to reproduce:

Opened up a link from an external program, with Firefox already running.

Actual results:

It opened the link and brought Firefox to the front / foreground.

Expected results:

It should have opened the link in the background, so i can open up many links quickly, as in previous versions of Firefox.

This is from Launchpad bug 1009816 by Lnxusr.
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1009816

Muchas Gracias!
Evan Peck ;~)

This is intentional. The old behaviour was incorrect, and was fixed in bug 721498

Chris,

I thought so too, but the reporter at http://ubuntuforums.org/showthread.php?t=1984331 is dead sure that it's a bug and not a feature request like I first said. Do I leave it, or change it to feature request?

Muchas Gracias!
Evan Peck ;~)

WHOA Whoops, I mean https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1009816

That looks like either wontfix or invalid

I'm going to reopen this because there is at least one bug:

The timestamp from the PropertyNotify event is the timestamp when the server changed the property. This could be somewhat later than the time the user clicked on the link.

I wonder whether we should only set the timestamp when we have a desktop startup id.

I wonder whether there is a fundamental reason why Owen said that its timestamp information "isn't something we can use when we're raising an existing window" or whether that comment was just based on the way the code currently handles the startup id.

Hmm, I was confused - when I said earlier:

> A proper "event timestamp" is passed over the remote protocol, but is thrown away because we also have a > "desktop startup ID". The "desktop startup ID" is useful when presenting a new window and includes the
> timestamp information, but isn't something we can use when we're raising an existing window.

I was assuming that the timestamp in:

void
nsGTKRemoteService::SetDesktopStartupIDOrTimestamp(const nsACString& aDesktopStartupID,
                                                   PRUint32 aTimestamp)

was the timestamp from the startup notification protocol, but as you point out, it's not that but rather the event timestamp for the PropertyNotify - so yes, it's not quite proper, and in very rare cases you could get unwanted focus stealing.

The timestamp from the startup notification protocol actually can be parsed out of the ID - SetUserTimeAndStartupIDForActivatedWindow() in the GTK+ nsWindow.cpp doe this using libsn, but it also can be done directly from the string value. (See http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt for how the timestamp is embedded in the launch ID.)

So before calling 'timestamp = GTKToolkit->GetFocusTimestamp();' it would be better to try and parse the timestamp out of the launch ID.

NOTE: That's independent from this bug report - the behavior reported here is as expected unless the user has gone off and interacted further with the originating window before the window is raised.

It's certainly possible to like the old behavior, but it's hard to justify it as a correct - why should Firefox come to the front when it isn't already running, but stay in the background if it was already running? A program like a terminal could offer an "open in the background" option for links which always passed a 0 timestamp to the startup notification spec so Firefox never took focus even if it was already running.

The old behaviour was likable for the same reason that the "open links in new tab in the background" option is likable (and is the default these days): it allows one to open a link without immediately context switching to it; instead one can continue with the task at hand, and switch at one's own time (and the flashing taskbar entry makes this easier). So personally I think it makes more sense for the implemented behaviour to be consistent with the value of the aforementioned setting, not with the startup behaviour.

I too was surprised when the new version of firefox started behaving in a new, surprising way, and I came to bugzilla to look for or file a bug.

Anyway, just my $0.02. Just because the old behaviour was the artifact of bug does not automatically mean it's not the desirable one. But of course it's up to the developers to decide what they want to implement.

I agree that the old behaviour was more likeable.

Funnily enough if you set browser.tabs.loadDivertedInBackground to true the Firefox window doesn't get focused / jump to the foreground anymore and doing this is therefore brought up as a solution to the problem everywhere. However this doesn't actually seem to be what this property is about - what the property seems to be supposed to do is to open that link (in this case from an external program) in a background tab. The fact that this doesn't focus Firefox is just a side-effect.

But opening links from external programs in background tabs is not what I want because that means that if I have loads of tabs open with, say, the first one active, and I then click on a link from an external application and later switch to Firefox, I still have to scroll to the tab I just opened.

See also https://bugs.launchpad.net/ubuntu-mozilla-ppa-bugs/+bug/703806 which seems to have made this workaround possible.

Interesting. I could fix this in Ubuntu itself now by using CompizConfig to set focus_prevention_level from low to high. Maybe some update had actually changed this setting because now everything behaves as it used to, i.e. the Firefox window wiggles in the task bar but doesn't go to the foreground.
I did actually update Ubuntu two versions or so to 12.04 recently but I'm sure this change had happened before that.