41813 - textbox.focus() will grab focus from other mozilla windows

Status: RESOLVED FIXED

(Core :: XUL, defect, P1)

Description

[Marko Macek]

If I start load/reload of bugzilla.mozilla.org page and then quickly switch to
another window the previous browser window will raise as the page gets loaded.

I am not sure what causes this but it happens on other pages too. :(

Comment 1

[Doron Rosenberg (IBM)]

i can't seem to repro on win98. Asa, any better luck?

Comment 2

[Asa Dotzler [:asa]]

I can't reproduce this under NT .

Comment 3

[Marko Macek]

It helps if the connection is slow :(
I can reproduce this many times even on other pages. I'll try to investigate
this more.

Comment 4

[Asa Dotzler [:asa]]

over to XPApps for evaluation

Comment 5

[Decklin Foster]

I'm seeing this on Linux, CVS pull @ noon 07/03. It seems to happen at random
with all sorts of pages, not just this one. If someone can confirm, please
change the title and OS.

Comment 6

[Chris McAfee]

Don, we need an owner for this.  m20.,

Comment 7

[Marko Macek]

This happens on many other pages too. I am not sure about Linux, but I will pay
more attention...

It could be related to page contents. I will try to find a test if this is so.

Comment 8

[Stephan Jaensch]

I have also noticed this bug (first I feared it was a "feature") and am finally
able to reproduce it here with Mozilla 2000071609 on Linux/Gnome/Enlightenment.

Step 1: open www.google.com
Step 2: open either www.javalobby.org or java.sun.com in a second window.
Step 3: switch to the google window, hit reload and switch to some other window
while mozilla is repainting. The google window will raise itself.

Oddly enough, you have to use google, using eg. mozilla.org does not trigger the
bug. Since both java.sun.com and javalobby.org trigger the "no plugin found"
window because of the java applets, it might be related to this. Note that
though google's page looks quite simple, it uses javascript (opposed to
mozilla.org). This might also be important...

I hope this helps find this nasty bug, as it was not simple finding a testcase.
The bug seemed to appear quite randomly...

Comment 9

[Marko Macek]

It's happening on Linux too, and also on other pages. Updating status. It can
also happen as frames are being loaded.

bug 44535 is possibly related.

Comment 10

[Marko Macek]

I have just seen this cause bug 39841. It can probably cause the bug 36172, too.

Comment 11

[cheng]

This seems to have disappeared on 2000080104-M17 on Linux.  Can someone confirm?

Comment 12

[sairuh (rarely reading bugmail)]

yeah, i cannot seem to repro using 2000.08.02.04-m17 [comm, beta2] bits on
linux, winnt or mac.

Comment 13

[cheng]

This is very reproducible on 2000080213 (M18) on Linux:

  - open two windows
  - on window 1, type into the location bar http://www.cnn.com/, press enter
  - quickly go to window 2 and click on the title bar to raise it (before the
    first window finishes loading)
  - when window 1 finishes loading, it raises itself.

Should this bug be reopened?

Comment 14

[cheng]

The procedure I posted shows the bug on 2000080204 (M17) and 2000080213 (M18) on
Linux.  Reopening.

Comment 15

[Steven Borrelli]

Confirmed the behavior that [e-mail] describes on Linux
(Red Hat 6.2) using 200080213 and using http://cnn.com as a test site.

Comment 16

[Marko Macek]

Still happens on windows build 2000080220 (bugzilla.mozilla.org is raised).

Comment 17

[Jesse Ruderman]

Attachment: test case

Comment 18

[Jesse Ruderman]

When a textbox in a non-active mozilla window tries to grab focus, we don't 
expect to notice anything until we switch back to that window.  But if another 
Mozilla window is front when the .focus() method is activated, the Mozilla 
window with the textbox jumps to the front.

Windows 98, Mozilla build 2000 082708.

Comment 19

[sairuh (rarely reading bugmail)]

jrgm? claudius?

Comment 20

[John Morrison]

On windows, it is (if nothing else) exactly what Nav4.x and IE5 do: when 
.focus() is set on a text input, in a browser window that is in the background,
that window will be raised to the top. (i.e., current windows behaviour is 
correct).

On mac, this raise is not the platform convention (per sfraser), and we do not 
raise the background window. (i.e., current mac behaviour is correct). 

However, on linux, we should not raise when .focus() is set, but in mozilla
we do (Nav 4.x we did not). (i.e., current linux behaviour is wrong).

Comment 21

[Jesse Ruderman]

i didn't know that other browsers did it as well, but i still think it 
shouldn't be that way.  it's annoying much more often than it's useful, 
afaict.  should this go to the "user interface: design feedback" component?

Comment 22

[John Morrison]

Ok, this comes down to two distinct issues then:
1) we raise on linux, and should not
2) an RFE to change the behaviour on Windows.

Can we call this the bug for (1), and a separate bug addressing the behaviour
on Windows can be filed for (2). 

Comment 23

[Jesse Ruderman]

split off bug 50665 for windows.  changing this bug to be linux-only.

Comment 24

[Claudius Gayle]

navtriage team sez: we say this is a 'future' bug for now.

Claudius sez: hey this looks like a toolkit thing. Reassigning to trudelle.

Comment 25

[Peter Trudelle]

trudelle sez Saari is Mr. Focus, reassigning.

Comment 26

[saari (gone)]

So this is an interesting bug. We've discussed this before, and it seems to be 
correct behavior for JS to be able to steal focus at any time. Now, being a mac 
user, this sort of thing makes my skin crawl. Being the person that has to muck 
around with the demon focus code, making the platforms behave differently in this 
case also makes my skin crawl!

I don't know what the "right thing" is in this case. 

Comment 27

[Jesse Ruderman]

saari - if you fix bug 50665 at the same time as this one, you might not need 
any platform-dependent code :)

Comment 28

[saari (gone)]

Except for one minor thing; there are many people that think the JS spec
specifies the current behavior.

Comment 29

[John Morrison]

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

Comment 30

[Matthew T (active 1999-2002)]

Where is the relevant JS spec? (I can't find it with Google.) I think it 
extremely strange that textbox.focus() should be considered to mean the same as 
{window.focus(); textbox.focus()}, leaving authors with no means of giving a 
textbox focus *without* also giving the window focus.

When Google, Bugzilla, etc use textbox.focus(), do you really think they mean 
to annoy the user by giving the window focus too? I don't.

Comment 31

[David B. Harris]

All the test cases I've seen use a text entry box of some kind. There's a place
to start looking(if nobody has found the source for the problem yet). I've
contacted a few authors of pages that do this, and they say, "No, I didn't
intend that! Thanks for letting me know, I'll look into it."

As an aside, I don't know how to navigator bugzilla.mozilla.org very well, but
this is something related: As far as windows are concerned under Linux, a Raise
is not the same as a Focus, they're completely seperate. A few window managers
treat them the same, but not many. Some platform-dependant code should be
modified so that when Mozilla wants to Raise a window, it should also Focus said
window. Thanks a bunch! :)

Comment 32

[Chris Siebenmann]

 Two pieces of information: first, this is independant of Javascript itself,
because I browse with JS off and this happens to me too on Linux. (fvwm2 is
my window manager.)

 Second: this is a very irritating and dangerous bug. Every time you steal
focus, the user's typing can suddenly go somewhere other than where they
expected and wanted it to go; this can have bad to very bad consequences
and is at the least annoying. Being interrupted in the middle of something
and losing part of your work generally does that.

 Explicitly stealing focus is evil and should be avoided unless there is
a truly compelling reason. Raising a window asynchronously can wind up
stealing focus, so it is almost as bad. (It also destroys the user's own
stacking order, which is bad in its own way.)

Comment 33

[Matthew T (active 1999-2002)]

Judging by comments on Slashdot at the M18 release, and by Chris here, I think we 
have more than one bug here. If Mozilla is raising the window on the completion 
of *every* page load with some window manager configurations (as some Slashdot 
comments suggested), please file a separate bug for that. If it is raising the 
window on some pages which don't use textbox.focus() or window.focus() (or when 
JavaScript is diabled), please find the common factor in those pages and file a 
separate bug for that too.

Comment 34

[saari (gone)]

This is annoying people, target mozilla 0.9

Comment 35

[Adam]

> If Mozilla is raising the window on the completion of *every* page
> load with some window manager configurations (as some Slashdot
> comments suggested), please file a separate bug for that.

Bug 55691

Comment 36

[David B. Harris]

My personal experience with this bug is that Mozilla only raises a window when the web page wishes a text-input box to have keyboard focus when the page is done rendering. I don't know what HTML that means, but I know it happens on plenty of pages without javascript.

Comment 37

[Kathleen :Brade]

adding my 2 cents here...

This is truly evil.  textbox.focus() (or whatever) should NOT affect the window;
just the widgets within the window.  (disclaimer: I haven't read any JS spec on
this but if it disagrees with me, I think the spec is *WRONG*!)

If I'm switching between a Navigator and Composer window, I don't expect the
Navigator window to come to the front while I'm typing in Composer.  The same
goes for Mail.  If I switch to a non-mozilla app, do I lose focus from that
window?  (I don't think so.)  This is really inconsistent.  We shouldn't allow
JS browsing so much reign over all of the windows in our mozilla apps.

Adding dogfood as a keyword since this is a major blocker for me using daily or
NS6 builds because the windows are constantly gaining/losing focus at unexpected
times and really slowing me down.

Comment 38

[saari (gone)]

target mozilla 0.8

Comment 39

[Peter Trudelle]

->moz0.9

Comment 40

[Peter Trudelle]

*** This bug has been marked as a duplicate of 28467 ***

Comment 41

[John Morrison]

verified. (consolidating this bug).

Comment 42

[Matthew T (active 1999-2002)]

Reopening based on Trudelle's 2001-04-06 comment in bug 28467.

Comment 43

[Peter Trudelle]

->hyatt

Comment 44

[Peter Trudelle]

->P1

Comment 45

[David Hyatt]

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

Comment 46

[Matthew T (active 1999-2002)]

Since bug 50665 (the Windows version) was marked as a duplicate, this bug is 
now All/All.

Again.

Comment 47

[David Hyatt]

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

Comment 48

[David Hyatt]

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

Comment 49

[David Hyatt]

Attachment: Patch to content DLL

Comment 50

[David Hyatt]

Attachment: Patch to DOM DLL

Comment 51

[David Hyatt]

Attachment: Patch to docshell DLL

Comment 52

[David Hyatt]

Attachment: Patch to embedding clients

Comment 53

[David Hyatt]

Attachment: Patch to appshell DLL

Comment 54

[David Hyatt]

Attachment: Patch to layout DLL

Comment 55

[David Hyatt]

The above patches fix several focus issues (including the one covered in this 
bug).  Ignore the patch to nsFileLocations in the appshell patch.  I only meant 
to include nsWebShellWindow there.

Comment 56

[Brendan Eich [:brendan]]

I asked for a comment explaining why you need to SetActive before the activate
message, and why Mozilla can't be as simple as the embedding GOTFOCUS/Activate
logic.  Hope Linux and Mac like this as much as Windows, also!  It'll come out
in the wash soon enough.

Other than that comment request, sr=[e-mail].

/be

Comment 57

[David Hyatt]

Fixed.

Comment 58

[Jesse Ruderman]

Filed bug 76621 for the textbox in the Search sidebar panel stealing focus from 
page content.

Comment 59

[:deanis74]

This is great, I'm glad it got fixed.  Is there a bug on self.focus() causing 
the same behavior?  I notice this when using, for example, hotmail.  If not, 
I'll spin off a new bug.

Comment 60

[Jesse Ruderman]

Several remaining problems:

bug 92252 http://www.messaging.sprintpcs.com/sms/ steals focus
bug 92879 textbox.select() still grabs focus from other mozilla windows

Comment 61

[Jesse Ruderman]

More remaining problems:

bug 124750 Other tab steals focus with javascript textbox.focus()
bug 138646 textbox.blur() steals focus from other windows