97067 - focus changes windows when background window finally loads

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[mwyner (gone)]

1) I have 2 browser windows open, let's say A and B.
2) There's some content I'm reading in A, but decide to go to another website in
B, so go to B's window, type some URL in the URL bar, and it starts loading that
page.
3) While I'm waiting for it to load (who knows how long it will take), switch
back to A and continue what I was doing.
4) When B's content finally loads, the B window comes to the front, overwriting
whatever I was doing in Window A, be it typing an email, reading a website, or
typing an AIM message. This is extremely annoying to always be losing focus like
this in the window I'm currently using.

Comment 1

[Chase Tingley]

*** Bug 97049 has been marked as a duplicate of this bug. ***

Comment 2

[Chase Tingley]

[e-mail] reports seeing this on 0824 and 0825 builds on Win98.  This
sounds like a regression of an old favorite, bug 77675.

Comment 3

[Chase Tingley]

*** Bug 97542 has been marked as a duplicate of this bug. ***

Comment 4

[Brian Ryner (not reading)]

I thought we had fixed nearly all cases of this happening.  Can we get an exact
sequence of steps to reproduce?

Comment 5

[John Morrison]

In a current mozilla trunk build (opt.)
1) open a browser window to http://home.netscape.com/
2) do right-click on 'N' image in page in upper left hand corner; select 'Open 
   in New Window'
3) When the borders of the new window show, do Alt-Tab to bring the first 
   window to the front.
--> the new window will pop back over the current top window
This was never quite totally vanquished, but got much worse sometime in the 
last (up to) 7 days. 

Comment 6

[r0polach]

Dupe of 92170, see comments inside it...

Comment 7

[Dvir]

This bug and bug 92170 say it's a problem with windows 2000. I see this on Win98
on all the builds of the last week.

Comment 8

[saari (gone)]

bah! Okay, I'll try to hunt down which change it was unless someone already
isolated the offensive first build

Comment 9

[saari (gone)]

works okay in 6.1, definite regression

Comment 10

[Dvir]

It's also working fine on 0.9.3

Comment 11

[Dvir]

I did some checking. The regression first appeared on the 2001082203 build.

Comment 12

[saari (gone)]

could be the GetEldestPresShell change

Comment 13

[Steve]

Not just Windows only. I'm seeing this on MacOS build 2001082704

Comment 14

[Peter of the Norse]

I'm seeing this on some of the new linux builds. Came someone with authority
change the platform/OS?

Comment 15

[Ryan Pertusio]

changing to

Platform: ALL
OS: ALL

(as always, if you disagree, change it back)

Comment 16

[Mike Young]

I'm sometimes seeing this much more forcefully than the old bug 77675. Today I
clicked to load a page in new window, and the the focus was stolen three times
in a row. I clicked back, clicked back, and clicked back. Only the third one
kept. It was never this bad before. Its almost like it steals focus while the
page is loading, not just after its done.

Comment 17

[my_name]

Me = Win98SE, 256MB, Athalon 900, moz= 0.9.3+ - 20010824

I saw this get 'fixed' in 0.9.3 - however that seemed to fix only the
_browser_ window. If the sidebar has not yet filled in before I ALT-TAB away
from the newly opened window then my focus gets stolen. If however I wait for
the sidebar (but not the browser window) to fill in, or I have the sidebar
closed, then I see no evidence of this bug.

Thanks to those working on this pesky bug.

Comment 18

[saari (gone)]

okay, found the offending checkin from jag:
08/21/2001 11:54jaggernaut%netscape.com mozilla/ xpfe/ browser/ resources/
content/ navigator.js 1.361 2/2  Bug 91884: postpone focus() calls from browser
onload till after the window is shown. r=jrgm, sr=hyatt

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/browser/resources/content&command=DIFF_FRAMESET&file=navigator.js&rev1=1.360&rev2=1.361&root=/cvsroot

Thinking of a solution, input welcome

Comment 19

[John Morrison]

Er, but that change (or almost the same change) was in 6.1, which was OK with
this fix. How did it work then?

Comment 20

[saari (gone)]

good question. Could be a compounding bug, but the other major candidate I saw
didn't relieve the issue by itself. I need to investigate more and see why that
focus steals on a timeout (it shouldn't).

Comment 21

[David Hyatt]

How is this code stealing focus so late?  This code fires when the onload
handler of the navigator XUL doc fires (right after a timeout).  The HTML page
shouldn't have loaded yet, but the reporter is saying that this happens after
the page in the window loads.

I'm confused.

Comment 22

[Steve]

At least on my MacOS build from 9/3, the focus will only be stolen in a very
short time after the new window is loaded. 

For instance, let's say I start with Window A and open a new link into Window B.
If nothing has loaded into B's window yet (text, graphics, etc. (excluding
window titlebar change)), and I switch back to Window A, then Window B will
steal the focus back.

However, if something has loaded into window B already (say the first image or
two of a set of images), I can go back to Window A without focus being stolen
back even though Window B is still loading.

Comment 23

[saari (gone)]

hyatt, look at jag's patch, he set timeout's on the focus calls, thus the later
response.

Comment 24

[David Hyatt]

But for the timeout to be delayed that much would be staggering.

(1) The onload handler of a nav chrome window executes and sets a timeout of 0
to focus.
(2) The window shows and the web page load gets kicked off (just barely started).

Now if jag's code is to blame, then that implies the user has time to deactivate
the window and activate some other window, all before this timeout manages to
fire.  I find that *really* hard to understand.  There should be ample open
space for the timeout to fire before the Web page loads (or before much of
anything else happens).

Backing jag out makes this go away conclusively?

Comment 25

[saari (gone)]

Attachment: Here is a simple little patch to fix the regression. However, it does not properly set focus to the window tabbed away from in this case. Need to think more about how to do that, but this can be used as a stop-gap if necessary.

Comment 26

[Ben Ruppel]

This is a pretty visible bug, and quite an annoyance.  Could the stop-gap be
implemented until a better solution is found? (OKOK, I can hear the boo-ing and
hissing)

Comment 27

[Diego Biurrun]

May god have mercy on us all bug 77675, the most hateful annoyance in mozilla
history has regressed. Please, please, please fix this for 0.9.4 even if it
delays the milestone a little. Use the stop-gap if no other solution is
possible. Else we are going to get *tons* of bugreports to duplicate and
dissatisfied users everywhere.

Proposing for 0.9.4 and rising severity to major since this adversely affects
the user experience a great deal.

Comment 28

[Gervase Markham [:gerv]]

I don't understand why we are _ever_ focussing windows which are not the
focussed window and are not Alerts. If I set the focus somewhere, I want it to
stay there :-)

I'm seeing this badly on Linux, BTW. jag: can you review the patch?

Gerv

Comment 29

[Diego Biurrun]

I am pasting Boris Zbarsky's comment from bug 77675 here to clarify why
focussing windows can be important for mozilla. Nevertheless we have suffered
long and hard from these problems and should maybe introduce some kind of "take
special care with everything that messes with window focus" policy.

Here it goes:

Whenever we bring up a dialog specific to a given window (eg security prompt,
save confirmation dialog, etc) we should be making sure that the window in
question is visible.  Otherwise it's not clear what window the dialog refers to,
 and this could lead to all sorts of problems, from work being lost to security
exploits based on tricking the user into believing that a security alert applies
to window A when it applies to window B.  This may involve deiconifying a window
and/or raising it.  For example, confirmation dialogs for saving partially
edited emails/editor pages when someone selects File > Quit fall into the
category of dialogs that absolutely require the parent window to be unminimized
and topmost.

Also, with modal dialog windows we have to make sure that the modal window is
above its parent at all times and is raised when the parent is raised.  Most
window managers to not handle this.
Futhermore, some Web applications (primarily intranet ones) rely on being able
to use window.focus() to raise windows since NS 4.x did so -- see bug 71266

Comment 30

[Gael Le Mignot]

That's strange, this doesn't happen on my computer. Mozilla build 2001090712,
OS: Linux (Debian unstable, X 4.1, Kernel 2.4.9-ac5, WindowMaker 0.65.1).
Maybe the stop-gap was used in recent builds?

Comment 31

[Jason Bassford]

> Whenever we bring up a dialog specific to a given window (eg security prompt,
> save confirmation dialog, etc) we should be making sure that the window in
> question is visible.

   If I right click on a link from site A and have it open in a new window, then
go back to site A, I do *NOT* want to have site B gain focus if there's some
kind of error - like not being able to contact the site.  Once I've gone back to
site A, I'm not interested in site B in any way until I actively go to the site
B window.  When I do go there *THEN* I can see the alert that's popped up on top
of the site B window.  The same goes with any other dialog.  If I'm not looking
at site B, I don't care anything about what it's doing.

	I don't want site B to steal focus from site A for any reason - dialogs can pop
up for the site B site but only in the (still background) site B window.

Comment 32

[jag (Peter Annema)]

Hmmm. Nope, that patch doesn't get my review. With that patch we'll create a new
situation where if you then tab back to the background window, its urlbar will
be selected instead of the content area, and we'll get a follow-up bug.

What's happening right now seems to indicate a problem with our event system, or
a misunderstanding of when this event actually has a chance to be scheduled.

I could back out my original patch and try a different patch which we used for
0.9.2:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/browser/resources/content&command=DIFF_FRAMESET&file=navigator.js&rev1=1.347.2.8&rev2=1.347.2.9&root=/cvsroot

Can one of the people here who is seeing this problem hack up their build to
have the above code and see if that addresses the problem? Note, if this is
indeed the problem, it will mean that if you get an ad popup (no locationbar),
it should display the same behaviour as discussed in this bug, but it will at
least be less visible (and make popups even more annoying, my hidden plan
*cackles*).

Comment 33

[John Morrison]

Actually, saari's patch doesn't "fix" the problem anyways. I think we should
go with what was done for 0.9.2 (which I was just in the process of testing,
and it appears to make things work OK).

Comment 34

[André Dahlqvist]

I have the same experience as Gael Le Mignot: this does not happen for me. I can
happily continue reading whatever I am reading in the first browser window while
the second window is loading and has finished loading.

I'm using 2001-09-07-21 on Debian GNU/Linux (Sid). I'm using FVWM 2.4 as my
window manager. Gael Le Mignot uses Debian Sid too, but I guess that's just a
coincidence.

Comment 35

[Greg Miller]

Focus-stealing during page loads has never really gone away for me, but the
remaining problems are a small fraction of the irritation that bug 77675 was.

Comment 36

[Jaime Rodriguez, Jr.]

Saari is out of the office, so I think this one is gonna have to wait unless
Judson reassignes. Propose nsbranch-.

Comment 37

[jag (Peter Annema)]

For the record, on the 0.9.4 branch I changed to code back to what we had on the
0.9.2 branch. On the trunk, everything is still the same, awaiting a patch from
bryner.

Comment 38

[John Morrison]

Jag, I suggest that we just check the same hack into the trunk, and that
we file a separate bug for you, saari and hyatt to figure out the open 
questions (like 'why was that focus-settimeout being serviced after layout
had kicked in?'). It's just not worth the aggravation to leave the defect 
in place.

Comment 39

[chris hofmann]

nsbranch+ until saari gets back and we can look at this in more depth.

Comment 40

[elaineking]

removed keyword nsbranch since it now has nsbranch+, per pdt mtg.

Comment 41

[Diego Biurrun]

*** Bug 96583 has been marked as a duplicate of this bug. ***

Comment 42

[saari (gone)]

jeez, you people need to keep your pants on. I'm back from Virginia, and I know
the right way to fix this. I'll get to it as soon as I dig out of my mail
backlog. Until then, please stop spamming the bug.

Comment 43

[Greg K.]

*** Bug 100456 has been marked as a duplicate of this bug. ***

Comment 44

[Jaime Rodriguez, Jr.]

Saari - IS there a stopper on the branch still or are we OK?

btw - chofmann is looking for his pants. are they in your cube.

Comment 45

[saari (gone)]

still a stopper, need to get a better patch in that jag has been testing

Comment 46

[David Gerard]

For a completely reliable test for focus stealing, try http://groups.google.com/ .

1. Go to the newsgroup view - let's say, netscape.public.mozilla.general -
   http://groups.google.com/groups?q=netscape.public.mozilla.general&meta=

2. Right-click on thread links, 'Open in New Window'.

3. Alt-tab back to the newsgroup view.

Steals focus for me every time.

(And if it's because they've done something funky in the source, I'll be
putting in an RFE to stop implementing it! :-)

Comment 47

[Greg Miller]

I just tried that, and I'm not seeing any focus-stealing. All I see is the new
window receiving focus when it opens, which is what I'm used to with Windows
apps. As I recall, there's another bug already open about finding a way to
defeat that.

Comment 48

[Fabian Schach]

David Gerard: I can confirm the mentioned behaviour with Mozilla 0.9.4 (Win98SE)
where focus stealing is *not* a problem usually.

http://groups.google.com/groups?hl=de&group=netscape.public.mozilla.general
If you right-click on any thread subject and open it in a new window, and then,
shortly after the new window is created, click on the title bar of the old
window to give focus to it, the new window grabs focus back once.

Greg Miller: Are you using 0.9.4 or a newer build? On 0.9.4 focus stealing was
fixed but does occur on the mentioned page.

Comment 49

[David Gerard]

>>If you right-click on any thread subject and open it in a new window, and then,
>>shortly after the new window is created, click on the title bar of the old
>>window to give focus to it, the new window grabs focus back once.


To be more precise: the new window seems to grab focus at the precise moment it
starts receiving data, i.e. when the progress bar changes from the barber pole
to a progress bar.

But ... I just tried it in IE 5.5 as well (5.50.4522.1800IC; SP1; q290108).
Guess what? The window steals focus in IE as well!

Not that that's an excuse for a window to be allowed to steal focus. Is there
any function (Javascript or whatever) designed to grab focus? [If so, is there
a pref to disable it?] I must confess my ignorance in such matters.

Comment 50

[mdimitrio]

Clearing up the confusion.

David Gerard wrote at 2001-09-28 05:36
> But ... I just tried it in IE 5.5 as well (5.50.4522.1800IC; SP1; q290108).
> Guess what? The window steals focus in IE as well!
>
> Not that that's an excuse for a window to be allowed to steal focus. Is there
> any function (Javascript or whatever) designed to grab focus? [If so, is there
> a pref to disable it?] I must confess my ignorance in such matters.

Javascript is being used by the Google site to grab the focus when the page
loads. This is the code:

<body bgcolor=#ffffff onload="window.focus();">

This code is present only in threads with more than 1 article, so if you pay
attention, you'll see that only those will steal the focus.

This doesn't seem to be the scope of this bug, which says "focus changes windows
when background window finally loads". It may have changed, but if it didn't, so
your report is invalid. If the scope of the bug was changed, well, so it's time
to update it's summary. Probably not the case.

Marcos.

Comment 51

[Phil Randal]

I'm not sure if this is the same bug, or another one, but in Windows if you load
a page and minimize Mozilla before the page has finished loading, lo and behold
it pops onto the screen when it is loaded.  

Comment 52

[John Morrison]

The nature of this bug is known. There is a fix that could go on the trunk, 
but they're looking at a more correct fix. So, please, let's just hold off
on further comments.

Comment 53

[saari (gone)]

Attachment: a better patch, test away!

Comment 54

[saari (gone)]

Attachment: jag pointed out that I boffed the last patch, try this

Comment 55

[John Morrison]

I was wondering about that :-)

Comment 56

[jag (Peter Annema)]

Comment on attachment 51347 [details] [diff] [review]
jag pointed out that I boffed the last patch, try this

>Index: xpfe/browser/resources/content/navigator.js
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v
>retrieving revision 1.370
>diff -u -r1.370 navigator.js
>--- navigator.js	2001/09/28 20:13:28	1.370
>+++ navigator.js	2001/09/28 23:51:46
>+    // set the elment in command dispatcher so focus will restore properly when the window does become active

s/elment/element/

>+    if (isElement)
>+	{
>+	  document.commandDispatcher.focusedElement = element;
>+	} else {
>+	  document.commandDispatcher.focusedWindow = element;
>+	}

You have tabs in here.

I'm wondering if we could/should do something like:

if (element instanceof Components.interfaces.nsIDOMWindow)
  document.commandDispatcher.focusedWindow = element;
elsif (element instanceof Components.interfaces.nsIDOMElement)
  document.commandDispatcher.focusedElement = element;
For now, r=jag if you fix the typo and the tab nits.

Comment 57

[dylang]

Someone mentioned Google/etc popping up.  Perhaps try adding

// Stops most onLoad/onUnload
user_pref("dom.disable_open_during_load", true)

To the prefs,js, or disabling Javascript to see if that causes the bug to manifest.

Comment 58

[John Morrison]

Are we considering the revised patch for landing on the branch? Or, is what
we have on the branch 'good enough' (noting that this bug is not present in 
the current branch builds).

Comment 59

[Jaime Rodriguez, Jr.]

pls let us now, when this patch get on the branch?

Comment 60

[David Hyatt]

sr=hyatt

Comment 61

[jag (Peter Annema)]

Attachment: Goofing off... Pick the one you like the best!

Comment 62

[Jaime Rodriguez, Jr.]

Pls come to the PDT tomorrow afternoon

Comment 63

[Jaime Rodriguez, Jr.]

Let's review this one in the PDT today.

Comment 64

[Boris Zbarsky [:bzbarsky]]

*** Bug 103490 has been marked as a duplicate of this bug. ***

Comment 65

[jag (Peter Annema)]

Attachment: saari's patch updated with my comment

Comment 66

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 52418 [details] [diff] [review]
saari's patch updated with my comment

r=[e-mail]

Comment 67

[jag (Peter Annema)]

Checked in on the trunk.

Comment 68

[Jaime Rodriguez, Jr.]

Should the fix that landed on the trunk, go into the 094 branch, or is it
already on the branch?

Comment 69

[jag (Peter Annema)]

On the 0.9.4 branch we currently have the same code that was used in 0.9.2/6.1
(but which we changed on the trunk for the worse, prompting this new patch).

This new patch would only make a few theoretical situations behave slightly
better, so I advice against taking this patch on the 0.9.4 branch, though
Mozilla.org may want it on the 0.9.5 branch (which still has the bad code).

Comment 70

[Asa Dotzler [:asa]]

*** Bug 98728 has been marked as a duplicate of this bug. ***

Comment 71

[ltskinol]

So.. I can't tell.  Is this fix supposed to be in the daily builds 
(/pub/mozilla/nightly/latest)?

Comment 72

[Jaime Rodriguez, Jr.]

Thanks for the update JAG.

Comment 73

[jag (Peter Annema)]

[e-mail]: yes.

Jaime: just "jag" will do :-)

Comment 74

[Boris Zbarsky [:bzbarsky]]

[e-mail]: yes.  It's in on the trunk as of Oct 7, 2001.

Comment 75

[Jaime Rodriguez, Jr.]

Fix is already on 094 branch - PDT+ (as a formality). thanks ... just jag. ;-)

Comment 76

[Hong Kwon]

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Comment 77

[saari (gone)]

fixed

Comment 78

[jag (Peter Annema)]

And checked in on the 0.9.5 branch (with a=Asa in e-mail).

Comment 79

[r0polach]

0.9.5 (2001101117): I still see the problem!

Comment 80

[John Morrison]

marking verified fixed. 

Open a new bug for further issues, and we can begin this merry dance again.

Comment 81

[r0polach]

Filled new bug 105225 describing this problem.
This CLOSED bug has 91 votes!
Please all, move your votes from this bug to 105225.