Firefox comes to front when opening link via external program.

[lnxusr]

Firefox 13 no longer remains in the background if opening a new tab from a different window, such as an email.

Prior to the upgrade, the only time Firefox would rise to the foreground was if it were not already running.

1) Ubuntu 12.04 LTS
2) The version of the package you are using: firefox 13.0+build1-0ubuntu0.12.04.1
3) See above.
4) See above.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: firefox 13.0+build1-0ubuntu0.12.04.1
Uname: Linux 3.4.1-030401-generic i686
NonfreeKernelModules: nvidia
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bjwest 2280 F.... pulseaudio
BuildID: 20120601173917
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
 Card hw:0 'SB'/'HDA ATI SB at 0xfd200000 irq 16'
   Mixer name : 'Realtek ALC887-VD'
   Components : 'HDA:10ec0887,10438444,00100302'
   Controls : 44
   Simple ctrls : 21
Channel: release
Date: Wed Jun 6 22:35:45 2012
ForcedLayersAccel: False
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
IpRoute:
 default via 192.168.1.1 dev eth1 proto static
 169.254.0.0/16 dev eth1 scope link metric 1000
 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.119 metric 1
IwConfig:
 lo no wireless extensions.

 eth1 no wireless extensions.
Plugins:
 Skype Buttons for Kopete - /usr/lib/mozilla/plugins/skypebuttons.so (kopete)
 Shockwave Flash - /usr/lib/flashplugin-installer/libflashplayer.so
PrefErrors: Unexpected character before close parenthesis @ [Profile]/extensions/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}/defaults/preferences/greasemonkey.js:4
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=13.0/20120601173917 (In use)
RelatedPackageVersions: kopete 4:4.8.3-0ubuntu0.1
RfKill:

RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: Upgraded to precise on 2012-04-28 (40 days ago)
dmi.bios.date: 05/30/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0503
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: M5A97
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0503:bd05/30/2011:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKComputerINC.:rnM5A97:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: To be filled by O.E.M.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Evan Peck (colors)]

Lnxusr,

Are you saying that,want you want is for, say, if I open up a link from Thunderbird, I won't see Firefox open, but it will open anyway? Is that the way it was 11.10 and earlier? If you can give an accurate description of what happens now and what you think should happen, this can be a feature request (since it's really not a bug), and get taken care of.

Muchas Gracias!
Evan Peck ;~)

[lnxusr (bjwest)]

@Evan,

What I'm saying is I want Firefox to act like it did before the upgrade in regards to focus policy.

The way it was before is that Firefox would only come to the front if there were not already and instance running. People often will go through their emails and/or RSS feeds clicking links, but not wish to go see or go to them until they are finished with all the emails/feeds.

Firefox 13 should, as it did before, remain in the background when it opens a new tab if that is my wish. Firefox needs honor the users settings/wishes as far as focus goes.

I tested this on my laptop, which still had FF 12.0+build1-0ubuntu0.12.04.1. I upgraded Firefox and only Firefox. Before the upgrade, Firefox remained in the background when I clicked on a link from an email. After the upgrade, Firefox no longer remained in the background when I clicked on a link from an email.

A major operational feature is no longer performing the way it did prior to the upgrade. This is a bug, not a feature request.

[Evan Peck (colors)]

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.

[Evan Peck (colors)]

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

Muchas Gracias!
Evan Peck ;~)

[Evan Peck (colors)]

Lnxusr,

Ok, now I get it.
I also reported it in Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=762374
and linked it upstream.

Muchas Gracias!
Evan Peck ;~)

[Chris Coulson (chrisccoulson)]

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

[Chris Coulson (chrisccoulson)]

Closing this, as it isn't a bug (see my comment on the upstream tracker)

[Evan Peck (colors)]

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 ;~)

[Evan Peck (colors)]

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

[Bugzilla-tf (bugzilla-tf)]

That looks like either wontfix or invalid

[Karlt (karlt)]

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.

[Otaylor-redhat (otaylor-redhat)]

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.

[Vasilis Vasaitis (vvas)]

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.

[Simon Reinhardt (simon-reinhardt)]

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.

[Simon Reinhardt (simon-reinhardt)]

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.

[Tim Angus (tim-ngus)]

Thanks for mentioning the focus_prevention_level tweak. This has been driving me mental ever since 12.04. It should really be a more user friendly/visible option though.