or "Windows steal focus from each other when page starts loading" again! Note: This problem was described many times: 77675 (fixed), 97067 (fixed) but I still see it (0.9.5: 2001101117) Reproducibility: Allways (use slow computer or be fast) Steps to reproduce 1. Have open window with any page containing a link. 2. Right click a link -> Open In New Window 3. Quickly switch to the first window (Alt-Tab or click-on-taskbar or minimize it...) 4. Wait... The second window takes focus and become to the front when second window loads the page. Correct behaviour: Focus should stay in first window. It is very VERY annoying. IMHO all code that unnecessarily focuses/raises windows should be removed (bug 88810) but please THIS case should have high priority: 77675 has 57 votes, dupe of it - bug 28467 has 10 votes, 97067 has 91 votes, ...
*** This bug has been confirmed by popular vote. ***
Note: The focus is stolen at the beginning of loading page (so you must be very fast for reproducing:)
Also seeing this on Linux ---> OS=All Reassigning this bug to saari, I believe he is the focus guru in mozilla. Sorry if I should be wrong.
>3. Quickly switch to the first window (Alt-Tab or click-on-taskbar or minimize it...) Minimize : this is a separate case, covered by bug 92170 For the rest of the bug: reporter, could you try a more recent build? Somehow I think the fix for bug 97067 might slipped from 0.9.5 (although 97067 bug report states clearly that it was included on 0.9.5 branch).
Can't reproduce it on NT4sp6a with 2001101503. Any specific pages you've seen this behavior with?
*** Bug 105272 has been marked as a duplicate of this bug. ***
as described in bug 105272 (marked as a duplicate of this bug), I still observe this bug on build 2001101117. this is very annoying.
Build 2001101803: still reproducible
it appears that if you enable quick launch, the behavior improves.
*** Bug 106450 has been marked as a duplicate of this bug. ***
sorry, I still can't get it to happen on my win2k box. Give me an idea of the OS and machine speed where I should be able to reproduce this.
Reproducing on WinNT4, Celeron 233MHz, 64MB RAM... if I have open some resource-eating (m$:) apps, it is pretty reproducible, just let your machine use swapfile in a right way;-) so you have more time to alt-tab... Note: ALWAYS reproducible, not only on a particular page...
Not sure if this helps, but I can trigger this with K-Meleon and "Open link in new window" on almost every page, since K-Meleon opens a new window in a blink. You have to be fast at switching back. Focus follows mouse and instantaneous autoraise should help reproducing this under Unix.
WFM on Nightly 2001111108, Win2k. Even after the two original bugs on this were fixed I was still seeing this problem, but now, I FINALLY don't see this anymore... Seems to have been working for at least a few builds now. Thank you!
I did a new install of 2001_11_17_08 for Win98 and the bug still exists for me.
Confirming on Linux with build 2001112006. Very annoying and recent regression I believe.
*** Bug 111253 has been marked as a duplicate of this bug. ***
*** Bug 96583 has been marked as a duplicate of this bug. ***
I still can't trigger this on my P3 500 Win2K box. I'll try to find a slower box, or one running 98. Still need to attempt to reproduce on linux.
See Bug 96583 for an easy way to reproduce this on Linux. With the technique in that bug, you don't have to quickly alt-tab or anything, as the window manager does the initial iconifying.
Ok I can easily reproduce this as mentioned in the previous comment with other WMs too. For example in the Sawfish you can set the matched window class to Mozilla-bin/mozilla-bin state iconified. When you open a new broser window by Ctrl-N it is correctly iconified. When you open it by Open link in new window it deiconifies just when the page starts loading. -> Updating summary
the deiconification is a seperate bug in my mind and in my 0.9.7 list. I can get iconified pages to jump up again on Win2k too, I just can't get windows to switch when they're both up (not iconified) via alt-tabbing. Believe it or not, those are seperate code paths :-)
Bug 96583, which only addresses the de-iconification, was duped against this one. Should we un-dupe it and change this bug to strictly apply to the focus grabbing?
Huh this is really strange bug. I have Linux 2001112706 build. I don't have any other focus/window related problems than this deiconification/unminimizing. I've tried hard to reproduce that fast alt-tab switch but I haven't noticed any problem.
Try it with MFCEmbed or K-Meleon. Open a link in new window and then alt-tab back to the original window. Reproducable every time on an Athlon 850.
*** Bug 114684 has been marked as a duplicate of this bug. ***
I've noticed this happening a lot lately (again)... right now using build 2001-12-12-03 under Win2k, but for the last couple of days the focus theft bug is back for me. Anyone else notice this too?
I've noticed it with build 2001121103. It only seems to happen if I click a link and then minimize the page though. And even then it doesn't come back to fully maximized, just comes up as a smaller window. And Mozilla is so fast on my Athlon 850 that I have to use the keyboard shortcut to minimize it or I won't get it in time. Running Win2k SP2.
Just started seeing this bug with today's build 2001121203.
What Warner Young was seeing is a new regression from the last 1-2 days, pages are now stealing focus _after_ finishing to load. It is described in bug 114930 and was apparently caused by the fix for bug 103758. I still see the classic focus stealing, though.
Most of the focus-stealing I'm seeing with 0.9.6 occurs during the resolving/connecting phase of a page download and is continous until the page load reaches a later stage. Unlike older focus-stealing bugs I've run into, this steals focus again whenever I click on another window (Mozilla or non-Mozilla). I've been hit by this very badly the last few days due to network problems slowing down page loading for me. The really fun part is that clicking stop doesn't end the stealing. The window has to be closed if I want to abort the page load with the focus-stealing continuing. This occurs on both FreeBSD 4.4 and Windows NT 4.0sp6a.
This is one bug that seems to keep coming and going... I remember it from months ago, but it seemed to be fixed later on; however, in the last few days it seems to be back with a vengeance. I'm currently using build 2002011103 on Win98.
On second thought, I think it may actually be bug 114930, marked as fixed, that's back again... it certainly seems to me that the stealing of focus happens upon *completion* of page load rather than at the *beginning* of the load.
I've also been noticing this happen when you minimise a browser window just after entering a URL, it pops back up as it takes back focus. Seeing this on Win98SE on build 2002011103 and the previous 3-4 days builds.
Have seen the problem consistently on OS X.
Platform PC; OS NT4; Build ID: 2002012203 Deiconification is present in this nightly build. I'm not sure if this is the correct bug, as bug 46988 ([win32] browser window doesn't stay minimized) looked more accurate. I have never seen this before, but wanted to check if something else had been fixed since 0.9.7. It happens even if I don't visit any auto reloading page at the moment, even though I may have so previously in the session. I now have the situation that I have several tabs visiting bugzilla in what I believe is the original window. I can iconize it without problem. If I create another window - blank page, iconize this one - then the new page, the blank page pops back up if no other application has an open window.
please test this again with a current trunk build, a focus fix just went in that may well fix the poping back up problems
I'm sorry, but the problem with deiconification on new windows (described in bug 96583) isn't fixed on Linux 2002013021 trunk build.
On Mac 9.1 (build 2002013008) it is better, but not completely fixed. I often keep two windows open (which overlap). Let's call them Windows A and B. I'll start something loading in A and then click on B to bring it to the foreground. And vice versa. What was happening VERY frequently was that window B would come to the foreground, but wouldn't immediately repaint the now uncovered region. There would be a pause, and then Window A would pop back to the foreground. (I also often drag links from A to B, expecting the page to load in the background in B while I continue to read A.) Test case: Open two browser windows, which overlap. Bring the right window to the top. Type www.dslreports.com in the URL box of the right window. Now (quickly) click on the menu bar of the left window. (Also can do it by refreshing www.dslreports.com in the right window) Expected result: Left window comes to foreground and previously hidden area is quickly painted. www.dslreports.com loads in background in right window. Actual result: Left window comes to foreground. The previously hidden area is not repainted. After .25 - .5 second the right window pops up to foreground. With the new build I can get it to fail on this webpage about 1/4 the time. The timing has to be right -- if I click on the left window's menu bar really quickly, the left page might get repainted first, and then the right window doesn't steal focus. Note: With the new build this problem is much reduced. But it still seems to take too long for the exposed area to repaint. It feels to me like some part of the page loading process in one window is blocking the repainting of other windows. I get the same feeling when I try to do other operations (such as clicking on another application's window to make it the active app) while Mozilla is loading a page -- it seems like the system is not responsive during that time. Is this another bug somewhere? I couldn't find it.
Ah! I think I see what you mean, running over a 56K link, the timing has to be just right; clicking on the second window as the first destroys its webshell but before the new webshell is up and going. I can get it best by hitting back or forward, but www.dslreports.com didn't seem to help really (in fact I haven't gotten it to happen with that in about 10 tries). Now fixing it will be another issue... but I'm pretty sure it is a problem where we bail out of a normal code path when dispatching the NS_DEACTIVATE event to the window because we're in a trasitional state between webshells. I think I'll have to find that bail point(s) and make sure the root focus controller gets the deactivate notification, basically from the else case of some if(!foo) check. But at least I see it :-)
ugh, at least with the mac case in comment #41, I don't think I can fix this anytime soon. Basically what happens is that our code doesn't come back to the event loop in time to process the deactivate before we check the window state during the page load. Might be able to muck with the layout timers, but it isn't the same bug as on Windows (which I think I have a fix for, but I won't be back to my PC to post it until next week).
I've noticed a similar problem with tabbed browsing, but couldn't find any bugs like it in the system. However, it seems closely related to this bug. I have Tabbed Browsing enabled in BuildID 2002022821, Linux. I'm viewing this bug page and I middle-click the Bug 88810 link to see what bug this one is blocking. Now, the result depends on whether I have also enabled "Load Links in the Background" or not. If I have, then the problem does not occur, but if I have not enabled background loading, then the new tab comes to the front (as it should). If it's a large page, however (as are many Bugzilly bugs), then I frequently switch back to the previous tab (by clicking) and continue reading. What happens now is that while the new page for 88810 is loading, it disables my navigation keys (PgUp, PgDn, UpArrow, DnArrow) in the tab that I was using (the one containing this bug). The situation can be remedied by several methods: - use mouse wheel - switch tabs using Ctrl-PgUp/PgDn - switch tabs using mouse ? any method of changing focus Steps to reproduce: 1. Enable tabbed browsing 2. Disable background loading 3. View this bug 4. Open link to Bug 88810 in a new tab 5. Quickly switch back to this tab 6. Observe navigation keys not functioning 7. Use scroll mouse, or change focus to other tabs somehow 8. Observe navkeys working again Expected result: Navkeys should work regardless of whether background loading is enabled or not. (Should I make this a new bug? Does someone know of this bug already? Am I in the right place?)
Not sure if this is the right issue, but today's download (build 2002030103, Win98) is changing focus on me at various times. Using 'N' to go to the next message and causing a switch in newsgroups, for example, brings the browser window to the front, over the mailnews window. This didn't happen in yesterday's build.
I see this after I click on the dialog to get headers in newsgroups, the browser window pops up in front.. this is really annoying. I was going to file a seperate bug on that, but checking first here if this bug may cover that.
this happens after I submit a form, and I thought bug 126850 might of fixed this.
hate to post again, but maybe this is all just bug 122765 I'm seeing.
Using build 2002-04-01(03) on WinNT, I'm seeing a weird new twist to the page-focus problem: The 2nd window grabs focus, I manually switch back to the 1st page but the windows don't shift. The 1st page will have all the indications of being in-focus (the title bar is bold color, the taskbar marker is "depressed") but it will be hidden behind the 2nd window.
The focus stealing in Windows is back. I confirm comment #49 on Windows 2000 build 2002040303. If you attempt to bring the first window to the foreground by clicking on the scroll bar or the status bar it stays behind window #2. You have to click on its title bar to get it to come to the front.
I think that might be bug 134317.
This has been observed again in build 20020407. I'm certain it wasn't happening in 0.9.9, so maybe something has changed since then? It's driving me insane - I'll be going to close a window, suddenly the focus changes and I close the wrong window.
WFM. The latest "page-loading-steals-focus" bug was bug 134317.
Worksforme on trunk build 2002-05-31-04-trunk and branch build 2002-05-31-08-1.0.0 on Windows 2000 and windows 98 ( using Alt-Tab or click-on-taskbar )
*** Bug 131699 has been marked as a duplicate of this bug. ***
Is there a way we can create a separate bug to track the problem in comment #41? This problem is still outstanding. See the responses in comment #42 and comment #43.