Closed Bug 72651 Opened 23 years ago Closed 23 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: 23 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: 23 years ago23 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: 23 years ago23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.