446568 - New window losing focus in 3.0.1

Status: VERIFIED FIXED

(Firefox :: General, defect, P2)

Description

[Matt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0

I've already mentioned this problem in this thread:

viewtopic.php?f=38&t=751215&p=3902355&hilit=focus#p3902355

But basically I don't use tabbed browsing, instead I have FF configured to open a new window when I click on a link from an external application. With 3.0.1 the new window doesn't have focus, and instead opens BEHIND the current window. If I revert FF to 3.0 then all is well, so obviously a problem with 3.0.1

I'm using Windows XP Pro SP2 on a 1.8GHz PC with an NVIDIA GeForce 7600 GS video card.

Reproducible: Always

Steps to Reproduce:
1. Ensure that Firefox is set to open links in a new window
2. Go to external application with a valid link to a web site
3. Click on link and watch the new window open, but without focus
Actual Results:  
See above and Details section

Expected Results:  
Opened the new window WITH focus

Comment 1

[Bill_MI]

I confirm this is a drastic difference for new Firefox windows.  I also set to open in a new window.

This bug also appeared with Firefox 3.0.1 in Windows 2000 and Ubuntu Linux 8.04.

The resulting location of the new window differs with what launches it:

Shortcut/Launcher from Desktop:
New window opens on the bottom of all other windows.

Shortcut/Launcher from Explorer Window:
New window opens behind the Explorer Window but on top of all other windows.

In all cases the new window lacks focus, differing from all previous versions of Firefox 1, 2 and 3.

Comment 2

[Mark R]

Confirmed again here. 3.0.1 on Win XP.
In my case, ctrl-n from FF launches new windows in front, but links from email launch behind other applications in the stacking order. It seems to happen randomly after a session restart. I've observed the same thing in older versions of Firefox too, also, it might be related to similar session problems where sometimes a window gets misplaced.

Comment 3

[Bill_MI]

Continues in version 3.0.2 (tested on a Win2K VM).

My workaround for Windows:
Install Firefox 3.0 over 3.0.1 or 3.0.2.
No bad effects have been observed.

Comment 4

[Matt]

I can't help but wonder WHY this hasn't been fixed in 3.0.2 - very annoying really. As soon as Google Chrome has Adblock support (or similar) I'll be dropping Firefox like a hot potato and moving onto that IF this problem isn't fixed soon.

Comment 5

[Wayne Mery (:wsmwk)]

suggest you look for other bugs which describe similar issues - this sounds like a dupe.

Comment 6

[Bill_MI]

Continues in version 3.0.3 (WinXP-SP2/3, Ubuntu 8.04/8.10 and Win2K-SP4-VM).

re: "sounds like a dupe"
The closest to another "New Window focus" type bug I see is for Firefox 2.0.0.16:
"FireFox no longer takes focus when clicking on links in external applications."
https://bugzilla.mozilla.org/show_bug.cgi?id=446294
But a comment mentions 3.0.1.

Only someone with more intimate knowledge could link 2.0.0.16 with 3.0.1 but descriptions suggest they may be related.

Obviously, something added/changed in 3.0.1 is responsible.

I continue to use Firefox 3.0 until this is fixed.

Comment 7

[Christian d'Heureuse]

I have the same effect with Firefox 3.0.4, WinXP-SP2.

When using the ShellExecute Win32 API function to open an URL, the new window opens in the background, when Firefox is already running.

The error only occurs when Firefox is already running.

Steps to reproduce:

1. Open Firefox and Tools / Options / Tabs.
Change "New pages should be opened in" to "a new window".

2. Keep Firefox open, open a command prompt window and type:
start http://www.mozilla.com

Result: A new browser window is opened, but it does not get the focus.

This error does not occur with Firefox 3.0.
And when Firefox is started maximized, the error also does not occur.

Comment 8

[Andrew Conkling]

This happens in 3.0.4 and has been confirmed by users on other versions of Windows and on Ubuntu, so the bug description should be updated to be more generic.

Comment 9

[Andrew Conkling]

(In reply to comment #5)
> suggest you look for other bugs which describe similar issues - this sounds
> like a dupe.

I used my best Bugzilla skills and found nothing related.

Comment 10

[Matt]

Hard to believe that I reported this four months ago and not only is it still a problem but the status still remains as 'unconfirmed'.

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> Continues in version 3.0.3 (WinXP-SP2/3, Ubuntu 8.04/8.10 and Win2K-SP4-VM).
> 
> re: "sounds like a dupe"
> The closest to another "New Window focus" type bug I see is for Firefox
> 2.0.0.16:
> "FireFox no longer takes focus when clicking on links in external
> applications."
> https://bugzilla.mozilla.org/show_bug.cgi?id=446294
> But a comment mentions 3.0.1.
> 
> Only someone with more intimate knowledge could link 2.0.0.16 with 3.0.1 but
> descriptions suggest they may be related.

Intimate knowledge not necessarily required. If someone finds the common bugs fixed in each perhaps one will jump out as the cause of this issue:
https://wiki.mozilla.org/Releases/ (they were released @ same time)
http://www.mozilla.com/en-US/firefox/releases/ should have links to bugs fixed

Comment 12

[PaulB]

Unconfirmed, my ass! This bug has been present in every update from 3.0.1 through 3.0.4 in both Vista and XP. Will this extremely annoying bug be addressed in FF3.1?

Because of security concerns I would like to upgrade from FF 3.0.0 but this bug is a deal breaker for me.

Comment 13

[Andrew Conkling]

Paul, I don't know if that attitude/language is going to win anyone any points here.... Also, many Firefox users (including myself) insist on single-window mode (basically the exact opposite of this scenario) so I'm sure that many Mozilla developers have never even noticed this.

Comment 14

[Bill_MI]

Andrew, well, nothing else is working and why would we care how developers run when they obviously do not care how we run?

Comment 15

[Wayne Mery (:wsmwk)]

Please make your comments count with information that adds to the knowledge about this bug, not banter.  See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html  

The normal standard for confirmation is when someone (for example a triager) with the privileges to confirm can reproduce, then it gets confirmed and it moves forward. Therefore, you're accusation about devs ignoring the problem is unfounded.  I am afflicted as well, and have the privs to confirm *but* I can't replicate it to my satisfaction.

An alternative to comment 11 is use the nightly builds from between the branch cut for 3.0.0 and the cut for 3.0.1, and to a binary search to get a one or two day regression range, then use the checkin log to find a likely patch that cause the problem http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=10%2F03%2F2008+11%3A38&enddate=10%2F04%2F2008+11%3A38  This is something someone with average computer skills can accomplish.

If needed visit firefox #bugday, runs every tuesday, or #qa on other days. QA can give you a hand doing the above or ask any questions you like about how to shoot this bug. http://quality.mozilla.org/events/bug-days

Comment 16

[Bill_MI]

Wayne, thanks for the pointers.  I found Win32 installers by non-intuitive brute force.  I've never browsed the nightly builds before but found this...

Last good version (Grand Paradiso):
ftp://ftp.mozilla.org/pub/firefox/nightly/2008/06/2008-06-30-09-mozilla1.9.0/

First version that shows this bug (Grand Paradiso):
ftp://ftp.mozilla.org/pub/firefox/nightly/2008/07/2008-07-01-06-mozilla1.9.0/

June 30 and July 1 2008 nightly builds.  Hope this is a start.  I'm working on how to tell what differences are.

Quick creation of the bug:
1) Tools -> Options -> Tabs -> New pages should be opened in -> select: a new window
2) Create a shortcut on the desktop to any site.  I use google.com.
3) Launch this shortcut by double-clicking it.  Firefox opens.  Don't close it.
4) Launch the shortcut again.
5) Firefox opens again in a second window behind the first window and without focus.  Before this bug was introduced the new window opened on top with focus, as it should.

Comment 17

[Christian d'Heureuse]

I can confirm the findings of Bill_MI. The bug does not occur with version 2008-06-30-09-mozilla1.9.0 (Gecko/2008063009) and it occurs with version 2008-07-01-06-mozilla1.9.0 (Gecko/2008070106).

Does this mean that is has to be one of the checkins between 06/30/2008 00:00 and 07/01/2008 23:59:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=06%2F30%2F2008+00%3A00&enddate=07%2F01%2F2008+23%3A59

Can we further narrow down the time of the checkins, e.g. 06/30/2008 09:00 - 07/01/2008 06:59, or what do the digits after the date in the version numbers mean?

Comment 18

[Bill_MI]

I may have it down to 7 events in the changelog using the timestamps of the nightly builds.

Specifically, revs: 15589 thru 15595 inclusive

CHANGELOG bridging this time:
http://hg.mozilla.org/mozilla-central/log/8d2c82ee9f0b

FIRST BAD NIGHTLY BUILD  20080701 14:08 UTC
ftp://ftp.mozilla.org/pub/firefox/nightly/2008/07/2008-07-01-06-mozilla1.9.0/

LAST GOOD NIGHTLY BUILD  20080630 17:45 UTC
ftp://ftp.mozilla.org/pub/firefox/nightly/2008/06/2008-06-30-09-mozilla1.9.0/

Further isolation appreciated.

Comment 19

[Christian d'Heureuse]

None of the changes of the changelog http://hg.mozilla.org/mozilla-central/log/8d2c82ee9f0b looks suspicious for this bug.
I think someone has to compile the intermediate source code revisions to find the culprit.

Comment 20

[Bill_MI]

Revision 15594 differences: http://hg.mozilla.org/mozilla-central/rev/6d88fe34dc34

This change is uniquely interesting in that it affects this file:
  dom/public/base/nsIFocusController.h

This is the most significant finding among the 7 revisions of Comment #18.

Comment 21

[u60234]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081128 Minefield/3.1b3pre.

After selecting the "Open new windows in a new tab instead" preference, clicking a desktop shortcut fails to bring the new window to the front.

Bill MI's regression range for mozilla1.9.0 builds is correct. However, these come from cvs trunk and not from mozilla-central, so the correct changelog for 3.0.1pre builds is http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&date=explicit&mindate=2008-06-30+08%3A00%3A00&maxdate=2008-07-01+07%3A00%3A00

mozilla-central builds regressed between 2008-07-03-03 and 2008-07-04-03, which gives this changelog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-07-03+02%3A00%3A00&enddate=2008-07-04+04%3A00%3A00

Common to those change logs are bug 441120. I did a local back out that confirms that the patch for bug 441120 is to blame.

Comment 22

[Robert Strong (they/them - no direct email)]

Shell integration doesn't come into play for this bug so moving back to Firefox -> General

Comment 23

[PaulB]

This bug is also present in FF3.1b2.

What does comment #22 mean?

Status has been changed to "new". What does this signify?

Comment 24

[cmtalbert]

(In reply to comment #23)
> This bug is also present in FF3.1b2.
> 
> What does comment #22 mean?
> 
That the bug was mis-filed into the wrong component and that it has been re-filed into the correct component in bugzilla.
> Status has been changed to "new". What does this signify?
This means that the bug is actionable - we have the information needed to fix it now, particularly with the great research that Hasse did in comment 21.

That research also shows that this is a regression and therefore should block 3.1.

Setting those flags.

Comment 25

[Samuel Sidler (old account; do not CC)]

We won't block a security release on this issue.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

I've been trying to reproduce this bug so that I can fix it, but I haven't been able to.

Could someone who's seeing this provide steps to reproduce that begin with "create a new profile using a recent trunk nightly"?

Comment 27

[u60234]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090221 Minefield/3.2a1pre

Steps to reproduce:
1. Create new profile, don't import anything, and set Minefield as your default browser.
2. Make sure the Minefield window is not maximized so you can see part of the Desktop.
3. On the 404 page for http://www.mozilla.org/projects/firefox/3.2a1pre/firstrun/, drag the "archived version of mozilla.org" link to Desktop
4. Go to Tools -> Options -> Tabs
5. De-select the "Open new windows in a new tab instead" checkbox, click OK
6. Double-click (or click, depending on your Windows preferences) the "archived version of mozilla.org" shortcut on Desktop to open it in Minefield.

Result:
The page opens in a new Minefield window behind the first window.

Comment 28

[:Gavin Sharp [email: [e-mail]]]

Ah ha, I can reproduce with those steps. Thanks!

Comment 29

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

This turned out to be pretty simple... the patch for bug 441120 made us take the new loadURI path for external link openings, and loadURI doesn't focus the content the same way loadOneOrMoreURIs does (via tabbrowser's loadTabs).

Comment 30

[Wayne Mery (:wsmwk)]

might recheck 446294 after this is fixed

Comment 32

[Sam Malenfant]

As the originator of the bug 446294 report, thanks for tracking this down and the fix suggested through comment #29.  This also seems to correct the same problem in 3.0.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6), though the line in "browser.js" for that version was 562 and the fix remained adding:
	  content.focus();

Comment 33

[Bill_MI]

Can someone tell us if this patch will be in 3.0.7 beta or how to find out?
Firefox 3.0.7: https://wiki.mozilla.org/Releases/Firefox_3.0.7
Much thanks Gavin, Hasse and others!

Comment 34

[:Gavin Sharp [email: [e-mail]]]

It's too late for 3.0.7. It should be in 3.0.8, though.

Comment 35

[Samuel Sidler (old account; do not CC)]

This is a regression from a security fix (bug 441120), so yeah, we should probably take it on both 1.8.1 and 1.9.0 (after it gets landed on trunk and 1.9.1).

1.8.0 drivers might want this too.

Comment 36

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/mozilla-central/rev/f151e6c4fbb9

Comment 37

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/releases/mozilla-1.9.1/rev/9d5b8a6c07b0

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 363553 [details] [diff] [review]
patch

approved for 1.8.1.21 and 1.9.0.8, a=dveditz for release-drivers

Comment 39

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.js 	1.479.2.223

Comment 40

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.js 	1.1041

Comment 41

[:Gavin Sharp [email: [e-mail]]]

That last comment means that this will be fixed in Firefox 3.0.8, in case that wasn't obvious to everyone following this bug report :)

Comment 42

[Al Billings [:abillings - ex-MoCo]]

Verified fixed in 1.9.0.8 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8pre) Gecko/2009031805 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).

Comment 43

[Dave Duperon]

I just installed 3.0.8.  It is NOT fixed.  I experienced it in 2.0.0.?? and just upgraded to 3.0.8 expecting to see it gone.  No luck.  I click an email link and don't get focus.  I open a command prompt and type "start http://www.google.com" and don't get focus.  Only happens when firefox is already running.  New windows open fine if they are the first.  All successive windows opened from external apps fail to get focus.  All new windows opened from withing Firefox get focus.  Can be reproduced every time using any of the methods described in previous comments and original post.

XP Pro, SP3, all updates current as of 15-Apr-2009.

Comment 44

[Bill_MI]

I think 3.0.8 was hurried out for unplanned emergency reasons, without the scheduled pieces.  Perhaps someone can confirm the dates here?: https://wiki.mozilla.org/Releases/Firefox_3.0.9

TIA (3.0 is getting old)

Comment 45

[Al Billings [:abillings - ex-MoCo]]

Bill, you're correct. The version number was bumped up due to a quick release for a security issue.

This bug is fixed in Firefox 3.0.9, which is currently in Beta. You can download it from ftp://ftp.mozilla.org/pub/firefox/nightly/3.0.9-candidates/build2/ or wait a week until it is released.

Comment 46

[Calc-Yolatuh]

Interesting. Glad to see this has been given attention. I should see if this affects other window-focus issues that I have had in Firefox. (Notably, the wrong window gaining focus when selected in the Windows taskbar. Even with other windows open, this behavior has been unique to Firefox.)

Comment 47

[Bill_MI]

A big thanks to everyone involved!  My first test says 3.0.9 is good to go.  Now I get to see what else is changed since 3.0.

Comment 48

[Sawan Gupta]

I still see the same problem in Firefox 3.0.9
When an external application launches a link, firefox looses focus.

To reproduce, open firefox (keep it in focus)
I have webshots installed, so press Ctrl+Shift+D to go to webshots website.
Firefox will loose focus.

Comment 49

[Dave Duperon]

Not fixed.  Fedora 10, Firefox 3.0.9, Thunderbird 2.0.0.21.  If Firefox is NOT open and link clicked in T-bird, Firefox opens on top with focus and successive link-clicks in T-bird open new Firefox windows on top with focus.  But if FF is alread open when first T-bird link clicked, new FF window is behind T-bird mail window and not focused.

Comment 50

[Al Billings [:abillings - ex-MoCo]]

Dave, you're on Linux? This was listed as a Windows specific bug and verified on Windows.

Sawan, what operating system are you using?

Comment 51

[Bill_MI]

Al, I see "Platform: All All" on this bug page.  Where would such a "Windows specific" status be "listed" or "verified"?

My Comment #1 included Linux and I recall it's been all platforms since then or maybe all along.  I would verify Ubuntu now but their repositories are rather busy today. :-)  I'll try.

Comment 52

[Al Billings [:abillings - ex-MoCo]]

Bill, read the bug's title. People often don't set the platform properly.

I forgot your comment #1. Please let me know what you find on Ubuntu.

In any case, I did verify it was fixed on Windows when I looked. Hence my questions to the others.

Comment 53

[Bill_MI]

Point taken, Al.  Learning this fact, is it possible to change the title and get such a characterization out of the picture?  Especially since I just confirmed...

Firefox 3.0.9 in Ubuntu Hardy 8.04, both Gnome and XFCE desktops, is NOT fixed for this bug.  Since Gnome handles URL launchers like a drunken sailor the distinction with XFCE is worth noting.

I use and test Windows URL links (*.lnk hidden extension) and Linux launchers (*.desktop).  I don't think there's any difference when launching from an application but those with specific examples should confirm.

Comment 55

[Sawan Gupta]

(In reply to comment #50)
> Dave, you're on Linux? This was listed as a Windows specific bug and verified
> on Windows.
> 
> Sawan, what operating system are you using?

NT32, Windows XP SP2

Comment 56

[:Gavin Sharp [email: [e-mail]]]

The fix was actually to cross-platform code. It's possible that a variant of this bug with the same symptoms still exists on Linux. If someone can reproduce it in Firefox 3.0.9 or later, please file a new bug about it, and CC me?

Comment 57

[Bill_MI]

The Linux symptom that still exists in 3.0.9 looks so similar to the Win32 symptom that was fixed in 3.0.9 I'd suspect the new code was somehow excluded.  I note it may not be in the global "Linux" release as I can only speak for Ubuntu repositories for 8.04 and now 9.04.

But that said, I found an interesting anomaly.  The XFCE window manager (xfwm4) masks the problem.  I think this is because of the way it's designed to place windows it ends up determining focus and level, ignoring what the application may be doing.  Just a guess.

But my earlier report that both Gnome (metacity) and XFCE (xfwm4) desktops still show the problem is incorrect.  When testing I forgot I was actually using a third window manager at the time (compiz).

I went one step further... I observed the behavior of Xubuntu9.04 (XFCE/xfwm4) on Firefox 3.0.8 it was released with and, yes, xfwm4 masks the problem there, too.  This supports this anomaly is NOT newer code being seen in Firefox 3.0.9.

Sorry so long winded but I'd hate to see bad reports coming from XFCE users. :-)

Comment 58

[Al Billings [:abillings - ex-MoCo]]

I've tried the test cases described above by people.

On Windows, all work fine in 3.0.10 *except* that when the webshots one in comment 48. In that instance, Webshots retains focus.

On Unbuntu 8.10, if I click on a link in Thunderbird and Firefox isn't open, Firefox will open and gain focus. This is running Gnome. The same thing happens when I click on .desktop files.

So, other than Webshots, I can't reproduce this issue with Firefox 3.0.10 on either Ubuntu 8.10 or Windows XP SP3.

Comment 59

[Bill_MI]

My conclusion is Gnome is doing it's own thing in recent releases.  Here's why...

As simplified a summary I can think of from Ubuntu/Gnome launching *.desktop files in new windows when Firefox is already running:

Ubuntu 8.04 / Firefox 3.0 - no problem.
Ubuntu 8.04 / Firefox 3.0.1 - problem started.
Ubuntu 8.04 / Firefox 3.0.10 - problem continues but fix should be in!!!
Ubuntu 8.04 is the current "LTS" - Long Time Support version (4 years I think?)
Ubuntu 8.04 included a controversial pre-release of Firefox 3.0.

Ubuntu 8.10 / Firefox 3.0.10 - no problem (thanks to Al in comment #58)

Ubuntu 9.04 / Firefox 3.0.8 - no problem but the fix isn't in!!!
Ubuntu 9.04 / Firefox 3.0.10 - no problem and fix should be in.
Ubuntu 9.04 is the current release that included Firefox 3.0.8.

FYI - Ubuntu version numbers are YEAR.MONTH.  8.04 is April 2008.  AFAIK, each Ubuntu version is running a different Gnome version.

I see no need to include other desktop managers, the discrepancies and my conclusion is shown with Gnome.

Comment 60

[Aakash Desai [:aakashd]]

verified FIXED on builds: 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090505 Minefield/3.6a1pre ID:20090505031205

and

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre ID:20090505031155

Comment 61

[Andrew Conkling]

(In reply to comment #59)
> Ubuntu 8.04 / Firefox 3.0.10 - problem continues but fix should be in!!!
> Ubuntu 8.04 is the current "LTS" - Long Time Support version (4 years I think?)
(3 on desktop, 5 on server. 4 average! ;)

> Ubuntu 8.10 / Firefox 3.0.10 - no problem (thanks to Al in comment #58)
> Ubuntu 9.04 / Firefox 3.0.10 - no problem and fix should be in.

Overall this sounds like the bug fix hasn't yet made it into Hardy. Not sure how they'll choose to proceed (e.g. a patch just for that, a backport, etc.) but it's definitely worth filing. Let me know if you'd like some help making sure that gets into Launchpad so the Ubuntu maintainers know about the problem. (I'd be happy to do it now but my time is limited right now, but seriously, let me know and I'll do it later. :)

Comment 62

[Dave Duperon]

Verified fixed on Windows 3.0.10 and Fedora 10, 3.0.10.  Thanks to the devs and users who got this straightened out!  Very trivial but annoying bug.

Comment 63

[Sawan Gupta]

I still see the problem in 3.5.7. Same steps as mentioned in Comment 48 above.

Comment 64

[Sam Malenfant]

I am familiar with the bug, but it seems to be quite OK in 3.5.7 on Windows.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

Comment 65

[Sam Malenfant]

(Oops, sorry for confusion.  It was OK in 3.5.7, but I've recently upgraded to 3.6 and it also remains OK.)