Closed Bug 105225 Opened 23 years ago Closed 23 years ago

Window which starts to load a page grabs focus (and deiconifies, etc...)

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: r0polach, Assigned: saari)

References

Details

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. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
xpapps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Note: The focus is stolen at the beginning of loading page
(so you must be very fast for reproducing:)
QA Contact: sairuh → doronr
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.
Assignee: pchen → saari
OS: Windows NT → All
>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. ***
Blocks: 88810
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
*** 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.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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
Summary: Focus changes windows when background window finally loads → Window which starts to load a page grabs focus (and deiconifies, etc...)
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.
Component: XP Apps → Event Handling
QA Contact: doronr → madhur
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.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** 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.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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).
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
Hardware: PC → All
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.
Keywords: nsbeta1 → nsbeta1+
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.
Target Milestone: mozilla1.0 → mozilla1.0.1
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.
QA Contact: madhur → rakeshmishra
WFM.  The latest "page-loading-steals-focus" bug was bug 134317.
Severity: normal → major
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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.
QA Contact: rakeshmishra → trix
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.