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