Closed Bug 46988 Opened 24 years ago Closed 22 years ago

[win32] browser window doesn't stay minimized

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 120155
Milestone:
Future

People

(Reporter: termite, Assigned: danm.moz)

References

Details

(Keywords: helpwanted, Whiteboard: original bug seems to be wfm, other comments seem to be 77675) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20000730
BuildID:    2000073008

occasionally, when minimising the browser window, it simply pops back up, making
it impossible to mimimise it.  Note that it never returns to a maximised state,
but rather to a restored state.

Reproducible: Sometimes
Steps to Reproduce:
1. open a browser window
2. minimise it

Actual Results:  window popped back into a restored state

Expected Results:  window should stay minimised

This is intermittent, but happens a lot on my system (win95, 96mb ram, 166mmx).
 It's been occuring in builds for the last two weeks or so.
it's happens occassionally on NT4 as well.
Seems to be a problem for particular browser window instances.  A new window
opened from one that exhibits the problem does not inherit the problem.
Very intermittent.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also, at least for me, it only happens when ALL windows (mozilla or not) are
minimized.  If any window is not minimized then the mozilla problem window does
not restore itself.  If I minimize the last non-mozilla window, then the problem
mozilla window restores itself - even though it was properly minimized while the
other non-mozilla window was active.

I think I have a reproducible case:
1. close mozilla if it is already running
2. minimize all other windows
3. start mozilla
4. goto http://bugzilla.mozilla.org
5. minimize mozilla
6. restore mozilla
7. repeat steps 5-6 about 4 times
eventually the minimize will cause mozilla to be minimized and then instantly
restored

nope, doesn't reproduce for me using sean's method above :(
->xpt, danm
Assignee: asa → danm
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
*** Bug 47032 has been marked as a duplicate of this bug. ***
dup of 45783?
Probably related to 45783.  But I can make it happen without loading a page.  I 
have the browser set to open on a blank page and can repro the problem with 
that.  But, the statusbar has the following text after I try to minimize:
Read: (my local drive and path)\bin\chrome\skins\native\global\skin\scroll-
up.gif

Why does it start reading in a gif when I minimize?

Internal loading msgs mentioned in previous comment is bug
http://bugzilla.mozilla.org/show_bug.cgi?id=47145
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: --- → Future
nominating for beta3.  Or did window minimization miss the feature train?
Keywords: nsbeta3
  This is pretty weird -- I've been able to reproduce it on a Windows 2000 system 
fairly readily. With the added twist that the window which refuses to be 
minimized is occasionally some undead thing consisting of nothing but an empty 
sizing border. Clearing the "future" milestone for now.
Status: NEW → ASSIGNED
Target Milestone: Future → ---
adding myself to cc: list since this affects mail windows minimized as well.

I saw this on the 8-2 mozilla m17 builds on Windoes NT.  I minimized the browser 
window before the page finished loading.
this IS bug 45783 someone make the call and kill one

*** Bug 47601 has been marked as a duplicate of this bug. ***
*** Bug 45783 has been marked as a duplicate of this bug. ***
*** Bug 47709 has been marked as a duplicate of this bug. ***
*** Bug 48015 has been marked as a duplicate of this bug. ***
*** Bug 48025 has been marked as a duplicate of this bug. ***
*** Bug 48116 has been marked as a duplicate of this bug. ***
*** Bug 48207 has been marked as a duplicate of this bug. ***
I tried it on several platforms, and reproduced it, not consistently, on Windows
95 original build (English and Italian versions), W95OSR2 (English), W98
(English and Italian), W98SE (Italian) and Win NT4 (English). 
*** Bug 48513 has been marked as a duplicate of this bug. ***
*** Bug 48581 has been marked as a duplicate of this bug. ***
nsbeta3+, due to the number of dups, but very low priority (P5) for M18
Priority: P3 → P5
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Note that P5 priority is below the cut, we are not committing to fix this for 
N6.
adding mostfreq keyword.
*** Bug 49426 has been marked as a duplicate of this bug. ***
*** Bug 49426 has been marked as a duplicate of this bug. ***
I cannot believe you are not commiting to NS6 for this.  It's an incredibly
annoying bug, and it's stuff like this that will prevent people from using
Mozilla/Netscape.  Little things are the most annoying to most people.  I would
recommend upgrading to P3.
*** Bug 49657 has been marked as a duplicate of this bug. ***
*** Bug 49696 has been marked as a duplicate of this bug. ***
really adding mostfreq kw. :)
Keywords: mostfreq
PDT would like this fixed, trudelle can we please get a higher P level?
Whiteboard: [nsbeta3+] → [nsbeta3+][PDT 9/1]
Updating [PDT 9/1] to [PDT Check]
Whiteboard: [nsbeta3+][PDT 9/1] → [nsbeta3+][PDT Check]
->P3, since this is now mostfreq, and the dups have much more likely steps to
reproduce.
Priority: P5 → P3
  Can't reproduce today. I know this has been a problem for a while, but today it 
seems tamed. I *could* reproduce it fairly easily with an M17 prefab build. I 
never could quite figure out what triggered it -- it doesn't necessarily happen 
right off the bat -- though the preferences window trick (from duplicate bug 
47709) seemed always to work for me. I've been unable in ten minutes of trying to 
make it happen with either an Aug 30 M18 prefab build or with a home-spun debug 
build. Giving thanks to the mystery coder what codes at midnight and calling it 
done.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
reopening.  I haven't had this in a while, but it happened with 083008 win32 
today.  Sorry magic midnight coder :(
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Whiteboard: [nsbeta3+][PDT Check] → [nsbeta3+][PDT Check] can't reproduce
I still can't repro on Win98.  Has the frequency dropped? We were getting 2-3
dups a day, but haven't had a dup for over a week  now.  Who is still seeing
this in the Netscape 6 verification builds?  A show of hands, please.
very rare now, only happened today and hasn't happened in about a week.
However, this is still a problem and may start occurring far more often again if
someone doesn't find what's causing the problem and fixes it.
I can't reproduce this with today's build. At any rate, danm can't fix what
he can't reproduce. This is a cut candidate unless this bug returns in it's
full quirky glory.
See dupe bug 50441: it tells a way to reproduce the minimize bug.
  Steps from bug 50441 don't work for me. That is, the browser behaves fine (as 
far as this bug is concerned, anyway), even if I add additional steps like 
multiple windows and other applications. I still can't see this bug happen. Seems 
quite (inexplicably) fixed to me. I agree that's worrisome, but I'm stymied for 
discovering a more solid fix.

*** Bug 51329 has been marked as a duplicate of this bug. ***
51329 is an "old" dup (Gecko/20000807)
lowering priority back to P4. We can't hold for bugs we can't reproduce, and
can't afford to spend more time in attempts to reproduce this while there are so
many other easily reproducible bugs we could be fixing.
Status: REOPENED → ASSIGNED
Priority: P3 → P4
Mass-moving P4/P5 bugs to Future milestone.  We just don't have any time left
for these, although we could still consider taking a good patch.  Adding
Helpwanted keyword.
Keywords: helpwanted
Target Milestone: M18 → Future
nsbeta3-
Whiteboard: [nsbeta3+][PDT Check] can't reproduce → [nsbeta3-][PDT Check] can't reproduce
i think i've a reproducable test case --although this *might* be another bug 
(y'all be the judge):

1. go to a page which automatically reloads itself periodically, such as 
tinderbox (http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey) or a 
realtime traffic page (http://www.wsdot.wa.gov/PugetSoundTraffic/cameras/).

2. minimize the browser window.

3. wait.

result: when the browser reloads its content, it automatically unminimizes. 
again, i'm not sure if that is this bug, or even expected behavior. nor does 
this test explain why this occurs with pages like bugzilla.mozilla.org, which 
doesn't reload automatically...
http://jrgm/bugs/46998/reloader.html

<html>
<head>
  <script>
   function selfReload() {
      document.location.href="reloader.html";
   }
  </script>
</head>
<body onload="setTimeout(selfReload,5000);"> 
   <p>will reload in 5 seconds</p>
</body>
</html>


is the simplest test case. This only happens on Windows, although I too am 
not sure if it is really the same bug. However, this doesn't really fit the 
profile for nsbeta3 bugs anymore (no one dies, and all).
*** Bug 53332 has been marked as a duplicate of this bug. ***
Bug has happened for me using both WinNT and Win98.  Only seems to affect the
master (first) browser window; additional windows minimize fine.
Updating summary so this is easier to find.
Summary: browser window doesn't stay minimised → browser window doesn't stay minimized
This bug apparently fell behind in priority list.
However, I believe this bug is one of the MOST annoying I have ever seen.
I can reproduce it most of the time with one mozilla window open, and ALL the 
time with two or more mozilla windows open. 
I am using Win95 and mozilla M17. 
Unfortunately I cannot test it on other platforms.
Here is when the bug happens:
- It only happens when I minimize the LAST non-minimized window.
- Usually the window popping back up is the first-opened mozilla window, but not 
all the time.
- Minimizing a non-mozilla window also produces the bug, if it the last 
non-minimized window.
- Sometimes when closing (click on the X in the top-right corner of the window) 
a mozilla window, it doesn't close, but instead stays in the background without 
content. I mean, it can still be minimized and activated by clicking on its icon 
in the taskbar, but it doesn't show any content and cannot be closed.
I am certain this last symptom has a relation with the "minimize bug".

I have asked a few of my friends and family members, and their unanimous answer 
was : "I wouldn't use it. Period." 
Basically this means that you cannot start a program that isn't in the "Start" 
menu, and I honestly believe this bug would make us lose a lot of MSWindows 
users (and it is probably the platform where we need the best performances).
Thank you for reading this (long) post, I hope I helped. I'll post any update I 
can find about this bug. 

Fabian:
It would be excellent if you could grab a nightly build or wait for M18 to come
out in a few days to try this.  Most think it is fixed in recent builds.  Thanks!
Keywords: mozilla0.9
> - Minimizing a non-mozilla window also produces the bug, if it the last 
> non-minimized window.

This is interesting. Could you please try to reproduce it with a recent build
and describe more detailed? Thanks.
Ben: yes, that's been mentioned before. I've even seen it happen. With M17. But 
not with a recent build. Not that I try every day, or anything.

I just grabbed the latest build of yesterday evening (10/6). Indeed, it seems
fixed, windows apparently minimize fine, without popping back up. I'll keep an
eye on this bug, if it happens again.
Thank you again and keep it up,
Fabian

This still happens in:
Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001025

It's mostly random, but seems to occur most often when a window is minimized
while it's in the middle of loading a page. When the page load is complete,
mozilla sometimes pops back up into a restored state in the foreground.

It's behaving a lot like a dialog box in that respect, by jumping out in your
face and getting your attention. Could this bug be a snafu with the window
properties?

> When the page load is complete,
> mozilla sometimes pops back up into a restored state in the foreground.

I also see this on Linux, jsut that the Window comes from the background into
the foreground.
Reproduce:
1. Open 2 Mozilla Navigator windows and a third, non-Mozilla window
2. Click on a link, which loads a complex page
3. Bring the other Mozilla window into the front
4. Bring the third-party window into the front
3. and 4. must happen before the load in the first window is complete. I am not
sure that you need both step 3. and 4. - either one might be sufficient.
Actual result:
First Mozilla window comes to the front after the load and draw is complete.
This completely interfers with mutlitasking-browsing, which I use heavily to
save time (while the page loads).
The bugs appears only intermittendly.

I am not sure, this is the same bug, since this bugs seems to be seen only on Win32.

Ben Bucksch:
What you see on Linux is bug 28467 / bug 60122
I'm still seeing this with build 2000112704 on WinNT 4.0. I can reproduce it
consistently with the following steps (YMMV):
1) open a single browser window
2) go to http://bugzilla.mozilla.org/query.cgi
3) create a relatively long query and execute it
4) minimize the window
5) when the new page is loaded (one saying Please Wait) the window unminimizes
6) minimize the window
7) when the results of the query is returned the window unminimizes again

Casey, that's a different bug - the browser window getting focus after page
load. This bug is about the window coming back again instantly (at least, so I
understood).
Ben: I imagine the itinerant focus on page load is the root cause of this bug. 
Maybe this bug is a duplicate of another, but in the absence of any other way to 
reproduce the problem (thanks, Casey -- your steps actually make it happen for 
me), I think we have a culprit.
Whiteboard: [nsbeta3-][PDT Check] can't reproduce → [nsbeta3-]
> I imagine the itinerant focus on page load is the root cause of this bug.
> Maybe this bug is a duplicate of another

Bug 28467

It happens on my Mac. I can bee working in Mail, and suddenly the browser window
pops up over the Mail.
Originally this bug reported the following :
"When minimizing a [browser] window, it pops *directly* back up, in a restored
state, and it is mainly impossible to get it to stay minimized -- it just pops
back up all the time."
Ok, so I was seeing this before, back in M17 (see my earlier comments above),
but M18 and all the following nightlies up to Netscape 6 and Mozilla0.7 do not
exhibit this bug. As far as I am concerned, this bug is fixed, and it has been
for a long time.
Ok, now for those who say they "still see this bug in recent nightlies" :
You are seeing bug 28467. This bug is not about a "window popping up suddenly",
it's about "a minimized window popping back up directly". Bug 28467 is the real
problem, but honestly this bug should be resolved fixed, the initial behavior as
reported is no longer apparent.
*** Bug 64981 has been marked as a duplicate of this bug. ***
Blocks: 64981
*** Bug 65886 has been marked as a duplicate of this bug. ***
I don't see the original symptoms of this bug (mozilla popping up directly after
minimizing) on win98se for build 2001031904.  In fact, I've never seen them.

I *have* seen the 'other' symptom reported in this bug about a minimised mozilla
window popping back up when starting a page load.

Other comments in this bug seem to indicate that the 'other' symptom stems from
bug 28467.  However, it looks like bug 28467 is about to be closed as
'worksforme'.  I have tried reproducing that bug as reported, and it also works
for me.

I still see the 'restore on start of page load' bug.  Is this symptom going to
be treated in thIS bug, or should I open another?  I can't find any other bugs
that might be dups of this.
This one has always been iffy. However, Casey A. Peel's case above (2000-12-06 
08:22) still reliably works for me.

*** Bug 72651 has been marked as a duplicate of this bug. ***
Yes, Casey A. Peel's case above (2000-12-06 08:22) works for me reliably, too. 
*However*, this bug is not about that error!  This bug (I understand) is about
the window *immediately* popping back up when minimized.  I have not seen that
happen.

I had thought (as others have in this bug...see Fabian Guisset 2001-01-29 12:05)
that Casey's case was a dup of bug 28467.  That bug was threatening to be closed
as WORKSFORME a while ago (it worked for me, too) and I thought that opening a
new bug to describe Casey's symptom would be appropriate (bug 72651).  If you
want to change the original scope of this bug or pass it off on another bug that
is possibly related with different symptoms, fine.  I just what to make my
reasoning clear.

This bug has been fixed. A Looooonnnnnggg time ago. I don't know how, or by
what, but it has been fixed. Can someone please mark it fixed so we can get it
off the m0.9 and most-freq radar.

I also dont feel that this blocks 64981, becasue people have been confusing this
bug for several others for a long time. I did see the behavior this bug deals
with, (popping back immediately) and I no longer see it.

Please mark this fixed and direct any comments for "Mozilla unminimizes when
given focus" to bug 28467
  I don't know for popping up immediately. The summary says nothing about 
immediacy. As far as I know, this bug is (now? always?) about a window 
unminimizing itself under certain circumstances, time frame undefined. And that's 
still happening with Casey's test case.
  As for its 0.9-ness, benb nominated it for that -- whoa -- half a year ago. I 
suppose our requirements have changed in the meantime. It's not making it in 0.9 
without being reassigned, I promise that.

danm, I nominated it based on the fact that, back then, this bug was about the
window in certain circumstances "resisting" to be minimized. Casey's case is IMO
by far not that bad. Nice to see that somebody actually cares about the
nominations, though :).
Marking WORKSFORME based on comments. In the unlikely case that this is still a 
problem, doubtless someone will open a new bug.

Gerv
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Arg!  No :p

There is *SOMETHING* in the code which causes Mozilla to request my Window
Manager raises it above other windows.  It seems to do it rarely, i.e. when I
have *just* clicked over to a new desktop and IceWM hasn't focused the window
there, or via I have raised another window via Gnome-tasklist-applet and it's
not yet recognized as having focus.

IceWM's code defaults to not letting other windows steal focus.  I think that
somewhere in the X11 specific parts of Moz lurks code which rampantly tries to
take focus, and which partially succeeds because it is beating the Window
Manager's own focus routines in a race condition.

The window which steals focus must be 1) in the process of loading a page (since
it steals focus right after it finished a load and stops the throbber), and 2)
not-minimized.
Dylan_G@bigfoot.com - what you describe does not sound like the symptoms for 
this bug. So I'm not going to reopen it :-)

Gerv
So who do I bug about Moz asking for focus when it does not need it?
See my comments from the 2001-01-29 above. The bug for what you are seeing is
bug 77675 (the older bug has been closed because it was getting too long). And
no need to "bug" anyone, because it's been a known issue for a long time.
PLEASE REOPEN THIS!

The damned 2001062608 build will NOT stay minimized.  It's a complete regression
to its worst state on X11!  I hate it!  Fucking thing will not let me load a
page on the background, because somewhere in the "page load done, stop throbber,
etc" code path it tells IceWM to get focus, sometimes sucking me across a few
desktops in the process.  Ive grepped the source for focus, but I can't make
deas/tails of the XUL code.  I don't have time to llearn your codebase, so could
one of you wizards please get IceWM and X11 on a box and run the thing
concurrently loading pages?  THEN fix it?  Thanks!
Ranting about *nix window manager issues on an old bug is not always the best
strategy.

This is a Windows bug. It is not a Linux bug. Never was, despite attempts to 
redefine the bug that way.

But, the infamous 'Casey A. Peel, 2000-12-06' example is still reproducible in 
the current code base _on_Windows_. And so I am reopening this bug on that 
point. But this bug is still 'Future'.

For the problems noted with IceWM on Linux, please file a separate bug report.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Check out bug 77675.

It seems to cover the 'Casey A. Peel, 2000-12-06' example.
It is marked All/All.It is being worked on.
It has lots of votes.

This bug should probably closed again with references to bug 77675.

I second djk on that. I would return this bug to FIXED/WORKSFORSOME and added
the Peel testcase to bug 77675. This bug should be reopened only in the case the
testcase continues to have problems *after* 77575 is fixed.
Keywords: nsbeta3
Summary: browser window doesn't stay minimized → [win32] browser window doesn't stay minimized
Whiteboard: [nsbeta3-] → original bug seems to be wfm, other comments seem to be 77675
Bug 77675 has been fixed. I mark this bug FIXED/WORKSFORME (as it was already
twice) on my own observations and lack of any reports to the contrary from June 29.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
It's back!  Build 2001092908 in Win2k.
Open a message compose window, type something, hit save, then minimize all
Mozilla windows, and it'll pop back up at you.

This bug showed up for the first time
for me on Win2k, build 2002012803.
I can't minimize the browser, ever.

Jason Stover: you are probably seeing bug 120155
Blocks: 113266
I was able to reproduce this bug on Windows XP Pro with Build 2002020406

1) Open the browser.
2) Maximize the browser.
3) Enter a URL 
   *** Not all URLs caused this problem.
       www.google.com and www.altavista.com worked consistently.
4) Minimize the browser before the page has loaded.
5) The browser will then restore itself to an un-maximized state.

The problem didn't seem to occur after new browser windows were spawned.
RKAa, 

any chance this actually affects that new bug, as many people do see what TJ
noted in that bug, maybe adding some blocker or dependency here?  I was also
thinking that maybe that code change actually unearthed this one again.. 
There could be a new bug here.  I was using a recent build on the NT
workstations at the local university.  When I minimized all the Moz windows, one
of the would randomly pop up.  It wouldn't popup into the maximized state it was
in before I minized it, but would instead be a large-ish chunk of the left side
of the screen (600x400?).

I was minimizing the windows via the taskbar click (since they've added IE to
the NT box basic config, this "feature" of the taskbar has been added).  Perhaps
this event is different to Moz, or perhaps once the last minimize event is
received, it "leaks" a restore event in the case all windows are now minimized.
.
No longer blocks: 64981, 113266
Status: RESOLVED → CLOSED
Reopening.  The bug is back.
2002032003 on Win95

On mozillazine.org the same problem with the same build on Win2k was reported.
Status: CLOSED → REOPENED
Resolution: WORKSFORME → ---

*** This bug has been marked as a duplicate of 120155 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE
Was the bug duped to bug 120155 to give the latter the 17 dupes it has? :-(
well no one actually fixed this bug here.. so it seemed to just get fixed by
another.. and this is the same issue that is part of the new bug.. so its very
logical that it was duped to the new bug, and no one has targeted, nor added a
patch for a fix on this bug, so there you have it.... and not just for the sake
of creating more.
Verified dupe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.