Closed Bug 134317 Opened 23 years ago Closed 23 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: 23 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: 23 years ago → 23 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.