Closed Bug 134317 Opened 22 years ago Closed 22 years ago

Mozilla steals Focus with page loading

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: Matti, Assigned: danm.moz)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [adt1]) 

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)
Keywords: mozilla1.0, nsbeta1, regression
CC danm: Is this a regression from bug 120155 ?

I first noticed this with 2002032903, Windows 98. It also happens in 2002032916.
-> danm, that poor soul.
Assignee: joki → danm
Have that bug too !

Build ID : 2002033109 under WinXP.
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 
happening.

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.

Thanks.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
*** Bug 135081 has been marked as a duplicate of this bug. ***
*** Bug 135190 has been marked as a duplicate of this bug. ***
*** Bug 135173 has been marked as a duplicate of this bug. ***
Adding nsbeta1+ and [adt1] per adt.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
Blocks: 134771
Would it be a redundant "me too" if I add that I also see this on Mac OS X
builds (right now 2002040108)?
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.
The stated test case fails on all win and unix -> all/all
OS: Windows 2000 → All
Hardware: PC → All
Any ETA on this?
Blocks: 135800
  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
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.
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']

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
window.
adding myself.
*** Bug 136177 has been marked as a duplicate of this bug. ***
Blocks: 136384
*** Bug 136378 has been marked as a duplicate of this bug. ***
Blocks: 135242
backed out fix for bug 120155. this will go away now.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 135242 has been marked as a duplicate of this bug. ***
Works in 2002041003 (Win98SE) -> VERIFIED

pi
Status: RESOLVED → VERIFIED
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.
Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
> Reopening.

Why?
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?
la la la.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.
adding fixed1.0.0 keyword to resolve this for the branch.
Keywords: fixed1.0.0
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.
Craig: See bug 120155.
Blocks: 88810
*** Bug 140174 has been marked as a duplicate of this bug. ***
Comment 32 still applies after the fix for bug 120155 has landed.  Build 2002042510.
QA Contact: madhur → rakeshmishra
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
This exact same bug shows up again in buid 2002121408. Can anyone verify?
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.
I see this bug on Windows XP Pro with SP1. Mozilla build 2002121408. A build
from yesterday doesn't have the bug.
the new bug on this is bug 185448
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.