Last Comment Bug 105225 - Window which starts to load a page grabs focus (and deiconifies, etc...)
: Window which starts to load a page grabs focus (and deiconifies, etc...)
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: -- major with 7 votes (vote)
: mozilla1.0.1
Assigned To: saari (gone)
: Trix Supremo
:
Mentors:
: 96583 105272 106450 111253 114684 131699 (view as bug list)
Depends on:
Blocks: 88810
  Show dependency treegraph
 
Reported: 2001-10-17 04:07 PDT by r0polach
Modified: 2008-07-31 10:11 PDT (History)
42 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description r0polach 2001-10-17 04:07:57 PDT
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, ...
Comment 1 Ubermonkey 2001-10-17 04:56:36 PDT
*** This bug has been confirmed by popular vote. ***
Comment 2 Doron Rosenberg (IBM) 2001-10-17 05:03:53 PDT
xpapps
Comment 3 r0polach 2001-10-17 05:15:32 PDT
Note: The focus is stolen at the beginning of loading page
(so you must be very fast for reproducing:)

Comment 4 Diego Biurrun 2001-10-17 05:30:08 PDT
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.
Comment 5 Dimitrios 2001-10-17 10:52:07 PDT
>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).
Comment 6 Greg Miller 2001-10-17 13:02:30 PDT
Can't reproduce it on NT4sp6a with 2001101503. Any specific pages you've seen
this behavior with?
Comment 7 Matthias Versen [:Matti] 2001-10-17 13:53:53 PDT
*** Bug 105272 has been marked as a duplicate of this bug. ***
Comment 8 Sam Steingold 2001-10-17 15:06:51 PDT
as described in bug 105272 (marked as a duplicate of this bug), I still observe
this bug on build 2001101117.
this is very annoying.

Comment 9 r0polach 2001-10-18 09:33:23 PDT
Build 2001101803: still reproducible
Comment 10 Sam Steingold 2001-10-18 15:00:06 PDT
it appears that if you enable quick launch, the behavior improves.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2001-10-24 21:46:07 PDT
*** Bug 106450 has been marked as a duplicate of this bug. ***
Comment 12 saari (gone) 2001-10-28 19:25:53 PST
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.
Comment 13 r0polach 2001-10-29 04:48:09 PST
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...
Comment 14 Diego Biurrun 2001-10-31 14:23:26 PST
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.
Comment 15 Brett Denny 2001-11-12 09:15:03 PST
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!
Comment 16 Ubermonkey 2001-11-17 17:12:39 PST
I did a new install of 2001_11_17_08 for Win98 and the bug still exists for me.
Comment 17 Olivier Cahagne 2001-11-20 10:22:40 PST
Confirming on Linux with build 2001112006. Very annoying and recent regression I
believe.
Comment 18 Frederic Crozat 2001-11-23 03:30:21 PST
*** Bug 111253 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2001-11-25 10:52:49 PST
*** Bug 96583 has been marked as a duplicate of this bug. ***
Comment 20 saari (gone) 2001-11-27 18:26:05 PST
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.
Comment 21 ltskinol 2001-11-27 21:54:20 PST
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.

Comment 22 Tom Mraz 2001-11-28 01:14:47 PST
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
Comment 23 saari (gone) 2001-11-28 03:41:57 PST
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 :-)
Comment 24 ltskinol 2001-11-28 05:49:37 PST
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?
Comment 25 Tom Mraz 2001-11-28 06:59:19 PST
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.

Comment 26 scratch 2001-12-02 15:58:31 PST
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.
Comment 27 Boris Zbarsky [:bz] (still a bit busy) 2001-12-11 11:25:58 PST
*** Bug 114684 has been marked as a duplicate of this bug. ***
Comment 28 Ariel Gonzalez 2001-12-12 12:10:56 PST
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?
Comment 29 yodatjm 2001-12-12 12:51:15 PST
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.
Comment 30 Dimitrios 2001-12-12 13:07:17 PST
yodatjm@mediaone.net: that is bug 92170.
Comment 31 Warner Young 2001-12-12 13:46:59 PST
Just started seeing this bug with today's build 2001121203.
Comment 32 Diego Biurrun 2001-12-13 03:15:42 PST
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.
Comment 33 Greg Miller 2001-12-13 06:29:46 PST
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.
Comment 34 Dan Tobias 2002-01-12 13:45:19 PST
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.
Comment 35 Dan Tobias 2002-01-12 13:52:09 PST
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.
Comment 36 David G King 2002-01-12 13:53:30 PST
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.
Comment 37 Philip Hoyt 2002-01-16 06:08:29 PST
Have seen the problem consistently on OS X.
Comment 38 Hans A Rosbach 2002-01-23 06:37:29 PST
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.   
Comment 39 saari (gone) 2002-01-30 12:06:40 PST
please test this again with a current trunk build, a focus fix just went in that
may well fix the poping back up problems
Comment 40 Tom Mraz 2002-01-31 00:00:11 PST
I'm sorry, but the problem with deiconification on new windows (described in bug
96583) isn't fixed on Linux 2002013021 trunk build.
Comment 41 Michael Schmitt 2002-01-31 22:02:03 PST
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.
Comment 42 saari (gone) 2002-02-03 23:05:53 PST
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 :-)
Comment 43 saari (gone) 2002-02-05 20:52:12 PST
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).
Comment 44 Jason Bechtel 2002-03-01 08:35:26 PST
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?)
Comment 45 Warner Young 2002-03-01 11:28:05 PST
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.
Comment 46 [not reading bugmail] 2002-03-07 02:40:48 PST
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.
Comment 47 [not reading bugmail] 2002-03-07 02:44:54 PST
this happens after I submit a form, and I thought bug 126850 might of fixed this.
Comment 48 [not reading bugmail] 2002-03-07 02:56:32 PST
hate to post again, but maybe this is all just bug 122765 I'm seeing.
Comment 49 Tony Tovar 2002-04-01 10:15:45 PST
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.
Comment 50 Michael Schmitt 2002-04-03 09:25:19 PST
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.
Comment 51 Andrew Hagen 2002-04-03 18:28:47 PST
I think that might be bug 134317.
Comment 52 Mark Mayo 2002-04-09 14:27:34 PDT
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.  
Comment 53 Jesse Ruderman 2002-04-21 16:39:53 PDT
WFM.  The latest "page-loading-steals-focus" bug was bug 134317.
Comment 54 Rakesh Mishra 2002-05-31 16:03:12 PDT
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 )

Comment 55 Michael Lefevre 2002-06-01 19:12:29 PDT
*** Bug 131699 has been marked as a duplicate of this bug. ***
Comment 56 Michael Schmitt 2002-08-15 10:07:03 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.