Closed Bug 72651 Opened 24 years ago Closed 24 years ago

mozilla restores minimized window on start of page load if no browser window has focus.

Categories

(Core :: XUL, defect)

x86
Windows 98
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: david, Assigned: danm.moz)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010319 BuildID: 2001031904 mozilla restores minimized window on start of page load if no browser window has focus. Oftimes, I click on a link and then minimize the browser window to do something else while the page loads. Once something starts to happen to the new page (start of page loading?), the browser window restores and takes focus. If I have multiple browser windows open, things behave slightly differently. If all other browser windows are minimized, and I load & minimize the last mozilla window, things occur as above; the loading window restores and takes focus. However, if I cause another browser window to have focus after minimizing the 'loading' one, it behaves correctly; minimized window stays minimized and without focus. Finally, if I have another browser window open, but without focus, the 'loading' window will restore itself on top of the other open browser window, but it won't steal focus from the app that has it. Reproducible: Always Steps to Reproduce: 0. open a single mozilla browser window 1. submit a bugzilla query 2. minimize the browser window Actual Results: The browser window restores and steals focus when the results page starts loading. Expected Results: The browser window stays minimized and without focus when the results page starts loading (and until I activate the window). A similar problem was reported in bug 46988, but that problem was mozilla windows popping back up _as soon as they were minimized_. In this bug, the window stays minimized until something starts loading. Another problem (Windows switch z-order when running a URL) was reported in bug 28467, and at first was believed to be the real cause of this bug's behavior. However, that bug is about to be closed as 'worksforme' (and it does, as reported). So apparently this here is a new and different bug that has been around for quite a while (can't remember exactly when it started), but not exactly reported.
->danm. thought it sounded like a dup, but maybe just thinking of 28467
Assignee: trudelle → danm
Bug 46988 has a long history, and I've been able to reproduce it only fitfully. In its long life, it has picked up a few variations. However, see Casey A. Peel's comment dated 2000-12-06 08:22, in that bug. He gave steps to reproduce which actually work reliably, even for me. And those are this bug. Closing duplicate. *** This bug has been marked as a duplicate of 46988 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
OK. I'm reopening this bug because it isn't fixed with build 2001041804 win98se. The repro steps listed above still work. I know this bug was closed as a dup of bug 46988, but that bug has been closed, referring any other problems to bug 28467. Bug 28467 has been closed as a dup of bug 41813, which in turn has been marked 'fixed' due to some patches. Since the chain of bugs leads from this one to that one, and this bug still exists, I'm reopening this bug to get it some attention (again). Sorry if I overstepped my bounds by doing this.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Based on the last several coments in bug 46988 it does look like this one should be reopened. I can confirm this bug with user agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.8.1+) Gecko/20010420 build id: 2001042012
Status: UNCONFIRMED → NEW
Ever confirmed: true
The steps in this bug and in bug 46988 (Casey's) have always shown the problem to me. But I just tried it on Win2K and Linux using a build made today. It worked! No thanks to me, but this problem does seem fixed now.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
It seemed to be working for about a day, but it was just hidden. I was able to reprodue it rather easily on Win98 2001060104. I also tested the builds from 0531...those *seemed* to work at first, but with enough effort, they also have the bug. For those older builds, you have to minimize the window rather quickly after activating an action to get it to pop up again. Running multiple mozilla windows also seemed to help me reproduce it. At any rate, this bug is unfortunately not fixed. :-(
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I also see this bug with build 2001060320, Win 95. It only happens when I minimize the window *very* quickly.
Using build 2001-06-04-01, Win2k sp1 Oooh goody goody. I finally get to add comments to a bug I could successfully find (and not create a dup)! OK, let me see if I can step up the description a bit: Open ANY link in a new window. Now either minimize it or switch windows, whatever it takes to lose focus on the new window. As soon as the new window spawns, it grabs focus no matter what. It appears that the focus is not being kept during window creation. Severity should be changed to major, OS to all. (It's at least Win-ALL)
*** Bug 84624 has been marked as a duplicate of this bug. ***
*** Bug 85531 has been marked as a duplicate of this bug. ***
bug 77675 is probably related (if not a dup)...
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505 I think this is the same problem: If Moz is minimized or on the bottom of the win stack, activity in a script or a timed reload causes Moz to push itself to the top of the windows stack in maximized (or restore) size. This steals focus from whatever I was doing at the time. It is more than slightly annoying.
this new problem sounds like saari's bug with general window focus issues. closing this back as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.