If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mozilla steals Focus with page loading

VERIFIED FIXED in mozilla1.0



Event Handling
16 years ago
6 years ago


(Reporter: Matti, Assigned: Dan M)


(Blocks: 1 bug, {regression})

Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt1])



16 years ago
win2k and a 3h CVS build.

1. Open 2 mozilla windows.
2. Load a bug URL in the first window ( bug 1234 )
3. Switch to the second window while the first one loads
4. If mozila starts loading, the first window steals the focus
   (but the second window in the windows tasklbar is still activated)


16 years ago
Keywords: mozilla1.0, nsbeta1, regression

Comment 1

16 years ago
CC danm: Is this a regression from bug 120155 ?

Comment 2

16 years ago
I first noticed this with 2002032903, Windows 98. It also happens in 2002032916.


16 years ago
Keywords: mozilla1.0 → mozilla1.0+

Comment 3

16 years ago
-> danm, that poor soul.
Assignee: joki → danm

Comment 4

16 years ago
Have that bug too !

Build ID : 2002033109 under WinXP.

Comment 5

16 years ago
Can we keep the amount of pointless and redundant spam to a minimum please.

We do not need any further confirmations of this bug. It's clear that this is 

If you wish to join the CC: list for this bug, then you should do as most 
people do: simply add your name and do not make a comment. Many people filter 
out all bugs where only the CC: list changes, so they do not get a notification 
for that sort of change.



16 years ago
Target Milestone: --- → mozilla1.0

Comment 6

16 years ago
*** Bug 135081 has been marked as a duplicate of this bug. ***

Comment 7

16 years ago
*** Bug 135190 has been marked as a duplicate of this bug. ***

Comment 8

16 years ago
*** Bug 135173 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
Adding nsbeta1+ and [adt1] per adt.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]


16 years ago
Blocks: 134771

Comment 10

16 years ago
Would it be a redundant "me too" if I add that I also see this on Mac OS X
builds (right now 2002040108)?

Comment 11

16 years ago
It wouldn't particularly be too 'me too', but this bug is fallout from a 
checkin to a win32-only source file [apologies that it's not directly 
stated anywhere above].

So, whatever you're seeing, it can't be exactly what this bug is about.
You could look for a Mac bug that describes your problem, or otherwise, 
file a new bug with steps to reproduce. Thanks.

Comment 12

16 years ago
The stated test case fails on all win and unix -> all/all
OS: Windows 2000 → All
Hardware: PC → All

Comment 13

16 years ago
Any ETA on this?


16 years ago
Blocks: 135800

Comment 14

16 years ago
  I'm being stymied. Hoping for a fix early next week.
  I just tried the test case with a linux build from this morning and did not
see this bug. Further, on Windows this bug is a regression caused by a change to
a windows-only source file. It's completely fixed by reverting that change. (But
of course that's not a good fix because it causes other regressions.) I'm
skeptical of the multi-platform assertion, and I'm moving this back to the
PC-only platform. Jeffrey, whatever you're seeing, I'm guessing it's window
manager specific. Can you pin it down to a particular WM or set of preferences
in your WM (and file a different bug)?
OS: All → Windows 2000
Hardware: All → PC

Comment 15

16 years ago
I think it's this bug that turns an open window with http://my.netscape.com into
a giant popup everytime the meta refresh kicks in...  wondering which bug fix on
windows would we back out to get back to the previous behavior and set of
regressions???  if we are cutting a moz 1.0 RC1 branch next, week we might want
to look at trading for that set of regressions over this bug.

Comment 16

16 years ago
the trade off is with bug 120155 (rev 3.409 of widget/src/windows/nsWindow.cpp)

[although I don't know if that also applies to your example of a 'giant popup']

Comment 17

16 years ago
I can confirm, on windows NT, the same sort of behavior chris hofmann sees with
my.netscape.com.  The diffference is I was seeing it with my.yahoo.com.  i.e. every 
20 minutes when it automatically refreshed that window popped in front of what
ever I was doing.  Further, it did this even when it was a nested tab in that

Comment 18

16 years ago
adding myself.

Comment 19

16 years ago
*** Bug 136177 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 136384

Comment 20

16 years ago
*** Bug 136378 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 135242

Comment 21

16 years ago
backed out fix for bug 120155. this will go away now.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
*** Bug 135242 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
Works in 2002041003 (Win98SE) -> VERIFIED


Comment 24

16 years ago
Hi pi,
as I see th situation, you set this bug to"verified"
If yes, I must tell you, that this might be not such a good idea, (or ar you new
member of QA ?)
Status "Verified" does not mean, that the bug purely by chance did not appear in
a special nightly which you used on a special system, but it means, that QA has
checked all circumstances of the bug and now really is shure, that the causes
for the bug all are eliminated.

Comment 25

16 years ago
Resolution: FIXED → ---

Comment 26

16 years ago
> Reopening.


Comment 27

16 years ago
As opposed to Reopen, should this bug be marked as Resolved/Fixed (awaiting
verification from QA) per Dan's back out (Comment #21 From danm@netscape.com) of
bug 120155, which should resolve this issue in daily builds, or are people still
seeing this on the 1.0 branch?

Comment 28

16 years ago
la la la.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 29

16 years ago
I know, from testing, that the checkin that was behind this bug was backed out.
-> rev 3.411 on trunk and rev 3.410.2.2 on MOZILLA_1_0_0_BRANCH 'danm' 
"reverting rev 3.409. this re-opens bug 120155 but fixes bug 134317 and bug 
135528. snif." 

What is it with focus bugs that makes everyone so loopy.

Comment 30

16 years ago
As per the advice here, I've just opened
http://bugzilla.mozilla.org/show_bug.cgi?id=137015 which seems like the same
thing on Mac OS X but maybe isn't. I thought I should mention it here, just in
case it actually is the same thing.

Comment 31

16 years ago
adding fixed1.0.0 keyword to resolve this for the branch.
Keywords: fixed1.0.0

Comment 32

16 years ago
I've been observing something like this bug in Build ID 2002041803 on Windows
2000. I've mentioned it in the comments at Bug 120155, but the description is
closer to this one, I think. To duplicate it, I click on a link to a page, then
wait for the URL bar to update. If I minimize the window after the URL bar
updates, but before the page renders, then the window restores itself. It is
very consistent on my machine, and has been happening for a while now.

Comment 33

16 years ago
Craig: See bug 120155.


16 years ago
Blocks: 88810
*** Bug 140174 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
Comment 32 still applies after the fix for bug 120155 has landed.  Build 2002042510.


16 years ago
QA Contact: madhur → rakeshmishra

Comment 36

16 years ago
Verified on the branch 2002-05-22-08-1.0.0 on Windows 2000.
adding "verified1.0.0" to the keyword
Keywords: verified1.0.0

Comment 37

15 years ago
This exact same bug shows up again in buid 2002121408. Can anyone verify?

Comment 38

15 years ago
I don't see it. If you see it, then open a new bug, as it would be a regression.
This bug should not be reopened.

Comment 39

15 years ago
I see this bug on Windows XP Pro with SP1. Mozilla build 2002121408. A build
from yesterday doesn't have the bug.

Comment 40

15 years ago
the new bug on this is bug 185448
You need to log in before you can comment on or make changes to this bug.