fixed18.104.22.168, regression, verified22.214.171.124, verified1.9.1
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
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.
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.
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.
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.
suggest you look for other bugs which describe similar issues - this sounds like a dupe.
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 126.96.36.199: "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 188.8.131.52 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.
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.
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.
(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.
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'.
(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 > 184.108.40.206: > "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 220.127.116.11 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
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.
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.
Andrew, well, nothing else is working and why would we care how developers run when they obviously do not care how we run?
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
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.
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?
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.
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.
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.
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.
Status: UNCONFIRMED → NEW
Component: General → Shell Integration
Ever confirmed: true
QA Contact: general → shell.integration
Shell integration doesn't come into play for this bug so moving back to Firefox -> General
Component: Shell Integration → General
QA Contact: shell.integration → general
This bug is also present in FF3.1b2. What does comment #22 mean? Status has been changed to "new". What does this signify?
(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.
Assignee: nobody → gavin.sharp
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
We won't block a security release on this issue.
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"?
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.
Ah ha, I can reproduce with those steps. Thanks!
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).
Attachment #363553 - Flags: review?(mconnor)
OS: Windows XP → All
Hardware: x86 → All
might recheck 446294 after this is fixed
Attachment #363553 - Flags: review?(mconnor) → review+
Duplicate of this bug: 446294
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:18.104.22.168) Gecko/2009011913 Firefox/3.0.6), though the line in "browser.js" for that version was 562 and the fix remained adding: content.focus();
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!
It's too late for 3.0.7. It should be in 3.0.8, though.
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [ready to land]
Target Milestone: --- → Firefox 3.2a1
Comment on attachment 363553 [details] [diff] [review] patch approved for 22.214.171.124 and 126.96.36.199, a=dveditz for release-drivers
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 :)
Verified fixed in 188.8.131.52 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2009031805 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).
Keywords: fixed220.127.116.11 → verified18.104.22.168
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.
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)
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.
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.)
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.
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.
Not fixed. Fedora 10, Firefox 3.0.9, Thunderbird 22.214.171.124. 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.
Dave, you're on Linux? This was listed as a Windows specific bug and verified on Windows. Sawan, what operating system are you using?
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.
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.
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.
No longer blocks: 446294
(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
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?
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. :-)
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.
Summary: New window losing focus in 3.0.1 under Windows XP → New window losing focus in 3.0.1
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.
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
(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. :)
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.
I still see the problem in 3.5.7. Same steps as mentioned in Comment 48 above.
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)
(Oops, sorry for confusion. It was OK in 3.5.7, but I've recently upgraded to 3.6 and it also remains OK.)
You need to log in before you can comment on or make changes to this bug.