Closed Bug 120155 Opened 23 years ago Closed 22 years ago

Browser window does not minimize (minimised window restores, won't stay minimised)

Categories

(Core :: XUL, defect)

x86
Windows 98
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: srbush, Assigned: danm.moz)

References

Details

(Keywords: platform-parity, regression, Whiteboard: [Hixie-P0][Hixie-1.0] [driver:asa] [ADT1 rtm][fixed on trunk])

Attachments

(4 files, 4 obsolete files)

In build 2002011503 (also appeared in January 11th build, but did not see it in
the build from the 4th.), when I attempt to minimize the window by pressing the
minimize button in the upper right, the window instead behaves as though the
restore button had been pressed.

However, if multiple browser windows are open, each window will minimize
successfully except for the last window on the screen which fails as described
above.
Works for me, build 2002011103 on Windows ME
Works for me build 2002011503 on XP Pro
I've been trying adjusting preferences, changing what items are shown
(view-->show/hide) etc.  but nothing I have done has been able to work around
the problem.  It still has problems in every case.

Is this possibly a reoccurrence of Bug #46988?

The symptoms sound identical to what I have been seeing, except that it is
happening in every case and the window is not reappearing as full screen, it is
appearing as a "restored" window (ie. whatever the non-maximized window size had
been last set to).

I have reloaded an older archived version I have (from August 27th) and the
problem does not occur.

Is there an archive of recent builds that can be accessed somewhere so that I
can find out which build started to have problems for me?
More information:
The problem ONLY occurs in situations where there are NO other windows from ANY
application that are not mizimized.

Here's what happened:
I was playing mp3s with winamp and found that I was unable to duplicate the
problem.  The minute I exited winamp, the problem reappeared.  I tried this with
other applications: Eudora, Word, Excel, even just having a directory window
open all caused the behavior to disappear.  Having winamp visible near the
bottom of the screen...
however, if I minimize all the windows of Mozilla, THEN minimize all the other
applications' windows, Mozilla suddenly reappears when the last window is minimized.

I found the archives, and have seen this behavior with 2002011503.  I'll check
previous builds as well, now.
More info:
I downloaded versions of mozilla-win32-talkback.zip from the following URL:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-01-15-22-0.9.4ec

as well as from other 2002-01-xx-xx-0.9.4ec directories and did not have a
single problem.

as soon as I reloaded the version of mozilla-win32-talkback.zip downloaded from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest

the problem reappeared.  In Help-->About, this later file lists the version as
0.9.7+ while the previous files which work okay list it as 0.9.4.2 (build
2002011520)
so it seems to be localized to the later version.
will keep experimenting tomorrow.
even more info:

found the various archived versions of 0.9.7+ 
from ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-01-xx-xx-trunk

each file downloaded was the mozilla-win32-talkback.zip version

and downloaded and tested two additional versions:
Jan 15th: 2002011503: problem occurs
Jan 11th: 2002011103: problem occurs
Jan 1st: 2002010103: problem does not occur

I'll narrow it down tomorrow
After further testing:

v0.9.7+ 
Builds 2002010508 and prior work
Builds 2002010608 and later exhibit the problem

bugs 107303 and 118666 seem to be identical to this bug.  (both bugs are
unconfirmed).

In particular, I am currently using the "Classic" desktop theme.
confirming with win2k build 20020117..

I see this the last few days. If you want to minimize the last window it pops up
again.
(last window maximized, press minimize, window pops up again but not maximized)
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
Keywords: regression
I see the same thing. I try to minimize the browser (full screen) but browser
pops back up but not in a full screen. Using 2002011703 Win build (Win XP). I
think this bug is a duplicate of bug 120372.
Looks like a repeat of 53563
-> default owner and QA
Assignee: asa → jaggernaut
QA Contact: doronr → jrgm
*** Bug 120372 has been marked as a duplicate of this bug. ***
This bug seems to be a clear duplicate of Bug #92170.  I posted a comment there
just a few moments ago that included my observation that other applications
windows served as well as Mozilla's to remove/block the bounce-back effect.

This one shows a lot of work tracking down when the problem first appeared. 
Given that work, it might be better to roll 92170 into this one by marking 92170
the dup.  (This goes against my usual attitude, i.e., "first come,first served,"
for determining which is the "dup".)

         Dale
dales@tcs.wap.org:This is NOT a dupe because this one is new and different.
Matti: I agree on a re-read of all of 92170.

This is, I believe a dup of Bug 118666 though.  

However, I like the Severity assigned (Major) to the problem in this report much
better than the Normal Severity assigned currently in 118666.

I am also hoping that this will be targeted at 0.9.8 which has the problem in
Build 2002012406 on a WinNT4 box.

Dale
*** Bug 121965 has been marked as a duplicate of this bug. ***
*** Bug 118666 has been marked as a duplicate of this bug. ***
present on Windows *.* but not others
Keywords: pp
OS: Windows 98 → All
so please leave it with a windows version.  All implies multiple os's
OS: All → Windows 98
*** Bug 122264 has been marked as a duplicate of this bug. ***
*** Bug 122466 has been marked as a duplicate of this bug. ***
NOTE: THIS INFORMATION HAS BEEN COPIED FROM BUG #118666
      THIS BUG REPORT IS VERY DETAILED AND SHOULD BE NOTED
-------------------------------------------------------------------------------

Problem Observed in/with:
a) Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020129
b) Classic Theme *ONLY*  (Modern Theme works OK)

With the following sequence of steps I am able to get the 'minimize' button to work.

Steps to Correct Behavior:
1) Close all Mozilla and non-Mozilla windows.
2) Open initial browser window.  Minimize button should be 'broken'.
3) Open 'new' browser window.
   (This can be done any number of ways: File->New, Help->About, etc.)
4) Minimize button on 'initial' Mozilla window should now work, so minimize it.
5) Click Minimize button on 'new' window 2 times.  It should remain visible.
6) Close 'new' browser window and enjoy the working 'initial' window.


Additionally, I have observed that the 'broken minimize' has some interaction
with non-Mozilla windows.

Reproduce it: 
1) Close all Mozilla and non-Mozilla windows.
2) Open an application (i.e. Notepad.exe)
3) Open a Mozilla browser window.
4) Switch back to the Mozilla window and minimize it (via the button).
   The Mozilla window should have minimized!
5) Minimize the non-Mozilla application.
   EEEKK! the Mozilla window has 'restored' itself.
   
Seeing this behavior would lead me to believe that the initial 'broken' Mozilla
windows is actually Minimizing and immediately Restoring itself.

It may also be worthy to note that on my Windows machine, I have a 'Windows
Keyboard' with the 'WinKey'.  I can force the initial 'broken' browser window to
minimize by using the 'WinKey + M' combination.
seeing this on w2k with build 2002012803 win32 trunk

seems like if I right click on the start bar, select Minimize All Windows, the
problem goes away.
I only see this on the very first browser window that gets opened.  subsequent
windows do not have this problem, I see it started to regress for me in the
1-21, or 1-22 build, but not as far back as other people here.
One big question, why is this a problem only with the 'Classic Theme' ?!  Is it
a problem with the Theme? or is the problem more base?  If you look at the
bugzilla query posted above by jag ('Checkins during that period') you will see
that there are quite a few checkins of work related to themes and WinXP. 
Perhaps that is the area that needs to be targeted for investigation.
Correction: Bonsai query...not Bugzilla!  DOH!

I'm pretty sure I've seen this happen in the modern theme on occasion, though
I've never been able to reliably reproduce it.
J Mosser> Is it a problem with the Theme? or is the problem more base?

I think the problem is more basic.  I had brought up build 2002012903 this
morning and somehow (I still haven't identified the details to do this) I got
the browser minimizing as it should in Classic Theme.  I have just now switched
to Modern, and now it won't stay minimized as described above and in 118666.

I'll be bringing up a 20020130 build shortly, so I'll know then whether I can
find the trickery path again ... I'm not counting on being successful though.

BTW, the detailed procedure copied over from 118666 for working around the
problem almost always fails for me ... but it did work ONCE ...

Later ...
            Dale
I have observed this problem with 20020123 classic theme on Win2K and with
20020130 modern theme on Win2K. The window just wouldn't minimize. It would
flash like it is trying to minimize and then restore again. With the 20020123
build, if I have the browser open and open chatzilla, then try to minimize
browser and then chatzilla, it appears that chatzilla forces the browser to
restore. Very odd.
With 2002013003 (talkback.zip version) on WinXP it strangely enough happens
sometimes, but not always (with the older it always happend).
I use Netscape 4.79 for IMAP mail, and Mozilla for all the rest. Having Moz
minimized and then minimizing NS opens Moz. The other way around Moz won't
minimize. I only have one window opened of them both, and tried using Moz both
with and without tabbing.
At least the above is what happens 90% of the time. For some strange reasons
that I still haven't managed to find out, it sometimes works as expected even
though I'm doing exactly the same tests as I just described above.
*** Bug 122784 has been marked as a duplicate of this bug. ***
*** Bug 122859 has been marked as a duplicate of this bug. ***
happens on win2k. Build 2002013103

The Way im producing the error is by clicking the mozilla icon in the quick
launch bar twice and then minimizing both windows. the Last windows you minimize
will restore itself.
*** Bug 122968 has been marked as a duplicate of this bug. ***
*** Bug 123053 has been marked as a duplicate of this bug. ***
*** Bug 123060 has been marked as a duplicate of this bug. ***
*** Bug 123042 has been marked as a duplicate of this bug. ***
The large number of dupes showing up over the last day or two seems to indicate
that this bug is manifesting itself a lot... though I haven't noticed it lately
myself.  A few weeks ago, it happened to me frequently, but right now I haven't
seen it.
The bug remains present for me in WinNT4 (SP 5).  I have found it easier to hit
the "magic path" to suppress the bug in the Modern Theme, though trying to find
a detailed consistent procedure that could be called a workaround remains
elusive for either Classic or Modern.
 
Thankfully, it's limited to Win32 builds ... doesn't hit my Macs since they
don't have the same kind of Minimize functions that Windows xxx uses and the
Mac's windowshade and hide functions aren't susceptible.

Later ...
           Dale
Taking a guess that the problem maybe is that the minimize code is not
initialized on startup of the first browser window. I dont get any JS errors,
but that has been the reason other stuff has failed before in other bugs that
didn't work the first time.
-> hyatt as the most likely candidate in the given timeframe.
Assignee: jaggernaut → hyatt
using build 2-2-08 w2k I dont see a problem with opening first browser window
and the fact that didn't minimize, cause it works for me in today's build.  I
dont any problem with any windows not minimizing.  weird.
It's always been sporadic and unpredictable for me... every once in a while it
happens, and I can never quite figure out just what triggered it.
*** Bug 123290 has been marked as a duplicate of this bug. ***
I was concerned by the drift toward "first window only" in this bug.  So I
explored the "universe" of combinations of QuickLaunch, Classic | Modern Themes,
and 0.9.8 |  trunk builds from 20020202.

I used 0.9.8 (2002020206) and trunk (2002020208) builds.

I found that the key was the opening theme.  QuickLaunch active or inactive and
build made no difference in the problem as of Saturday's builds.

1.  If the browser was launched into Modern theme, minimization worked as
expected, desired, and required from the very first window.

2.  If the browser was launched into Classic theme, attempts to minimize a
single open window resulted in bounce-back failures indefinitely.

3.  If the browser was launched into Modern theme (where minimization worked)
and then was switched into Classic, minimization then failed indefinitely.

4.  If the browser was launched into Classic theme (minimization failing) and
then was switched into Modern, minimization CONTINUED to fail indefinitely.

5.  If the window in 4 was closed and reopened in Modern, minimization worked as
required.

As noted earlier in this bug, the presence of a second window alters the
bounce-back behavior.
 
But it's clearly not the first window only and it does appear to be a problem
for the Classic theme.
 
These results apply to an NT4 system w/ SP5.

         dale

I think I also found a breakthru here for the problem.. 


Something strange I noticed using build 2-2-08 on w2k classic theme, I was had
two windows open, the last one in the back was trying to reach a website, and I
tried to close the window, but it would not minimize.  Not till I stopped the
throbber.  Then It would minimize.

Dennis:

The problem has always been resolved when there are two or more windows open ...
ANY windows in any application will do.  In that condition, in Classic with the
problem, the Mozilla window will minimize and stay put UNTIL you minimize the
last window on the desktop ... then it pops up into a restored window.

There is one situation described above that blocks the unminimizing:
1> Open two Mozilla windows
2> Minimize the background one ... it stays
3> Attempt to minimize the remaining one (NO OTHER unminimized windows at this
time) ... it doesn't stay minimized.
4> Attempt again to minimize ... it doesn't stay again
5> Close the unminimized window.
6> The remaining Mozilla window remains minimized so long as you don't
unminimize it and you are free to minimize any other windows without that window
unminimizing on its own.

This was described above in Comment #24 copied over from Bug 118666.

I had not seen the throbber effect ... never tried to minimize while a page was
loading.

           Dale
I downloaded the currently nightly build: 2002020208 
and it happens to me no matter what theme I have running. even third party. for
the record I am on win98se
something I just noticed. after I sent that last update. If I open a second
window and then close it. the first window minimizes properly.
Tried switching to the modern skin, and it minimizes correctly on Build 2002013103

I recently moved back to the last milestone and noticed that between the last
milestone and the daily build, there was a change in the skin routine. the daily
builds would switch to the skin instantly, while the milestone builds would
require a restart of Mozilla.

could this change have caused this bug to occur?
Status: NEW → ASSIGNED
Target Milestone: --- → Future
as of 02/04/02 w/ build # 2002020409. still occuring. 
Pulling back in. This is too basic to not fix. 

To summarize (or at least firm up the target task at hand):
1) this started occurring with the 01/06 builds (thanks Steve Bush)
2) the checkin window has a URL above (thanks Jag)
3) the most significant window-related changes belong to hyatt, although
   I tried backing out all those changes and the bug is still reproducible
   (unless I botched the backout; quite possible, since other changes 
   have gone in on top). 
4) I debugged enough to know that a WM_SETFOCUS is dispatched to the mozilla
   window when the last window (of any app) is minimized to the taskbar. This,
   by intent, will raise the mozilla window out of the taskbar, but I don't 
   know why a focus is happening.
5) the simplest steps to reproduce are (according to moi :-)
    i) set them to classic skin
    ii) close all running applications
    iii) bring up windows explorer and navigate to mozilla bin directory
    iv) double-click on mozilla.exe
    v) click them minimize widget on the mozilla window
    vi) click the minimize widget on Windows Explorer
    vii) mozilla window will rise out of taskbar, on a focus event
(I can't reproduce this in modern). (I was using win2k to test).
Keywords: nsbeta1
Target Milestone: Future → ---
here is something else that will help:

in build 2-4-09 w2k classic, I noticed that if I hit the maximize button, then
it maximizes my browser window, then you can click on the minimize button and it
will do the same thing that the maximize button does at this step.  

So minimize button appears to be linked to maximize functionality somehow. 

Before you do that you *cannot* go to the taskbar > right click > _minimize, or
get the minimize button to work.  

After you do that you *can* minimize the window using the minimize button or
taskbar > right click > minimize.



*** Bug 123533 has been marked as a duplicate of this bug. ***
I am seeing this with 0.9.8 under windows NT: when I try to minimize the
only browser window, it goes down for an instant, just to reopen itself
right where it was. 
*** Bug 123556 has been marked as a duplicate of this bug. ***
I'm also running on WinNT4 and have found this problem in both the 0.9.8 release
(Build ID 2002020406) and in the trunk build (Build ID 2002020409).

I did discover something in following up on the following quote from messege #55
in this bug:

<dman84
Before you do that you *cannot* go to the taskbar > right click > _minimize, or
get the minimize button to work.  
/dman84>

I launched Mozilla and then did a taskbar > right-click > Minimize All Windows
The Mozilla window did minimize and stay minimized and continued to minimize
normally in Classis Theme so long as I did not close all Mozilla windows.

On initially launching Mozilla (or opening the first window if using
QuickLaunch), Mozilla would not stay minimized in Classic Theme.  It also
returned to this failure behavior whenever all windows had been closed and a new
window was opened.

In all cases, the taskbar > right-click > Minimize All Windows was able to block
the behavior and seems contradictory to the observation made in #55 on the Win2K
OS.  I don't have any other Win xxx OS to test on.

I really do hope this problem gets fixed soon ... it louses up 0.9.8 and most
users will miss the way to duck the problem.

          Dale
in build id # 2002020409 and win98se show desktop (windows key + d) will
minimize. but no other methods works correctly.
*** Bug 123702 has been marked as a duplicate of this bug. ***
Seeing the Mozilla window bouncing back to un-minimized state after clicking on
"minimize" icon in the control box on NT4 SP6a (Mozilla BuildID 2002020406)
immediatly after fresh install. I had V.0.97 before - was fine. 
Also: If I open a second browser window, I can minimize the first window.
If both are not minimized (although not maximized either), and then closing one
of the two by clicking on the "close" icon in the control box (right side of
the title bar), the "closed" app loses the main body of the window, letting me
see  the desktop workspace, but leave the "closed" mozilla title bar on screen.
The only way to kill it is through the task manager.
nightly build 2002020603 corrects. 
correction to my last nightly build 2002020603 changes bug it doesn't fix it.
now as long as I have another window (for another program or another mozilla
window open) the main browser window will minimize. if it is the only window on
my desktop that is open it still will not minimize. 
We need this targeted at 0.9.9 (the next few weeks, that is), and fixed.  Who is
going to do it?

/be
Blocks: 122050
Bug is also existing in the German localized version:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:0.9.8) Gecko/20020204
BuildID:    2002020406
Build ID 2002020603
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020206

Exploring the failure to minimize some more, I have a bit more detail (hopefully
not repeating something reported before.)

My conclusion is that item 4 in John Morrison's Comment #54
>>>>>>>>>>>
4) I debugged enough to know that a WM_SETFOCUS is dispatched to the mozilla
   window when the last window (of any app) is minimized to the taskbar. This,
   by intent, will raise the mozilla window out of the taskbar, but I don't 
   know why a focus is happening.
<<<<<<<<<<<<

can be made more specific:
 "... a WM_SETFOCUS is dispatched to the CURRENT LAST-CREATED mozilla window ..."

I believe that determining why this focusing is occurring will be the key to
solving the problem.

Now, the test:

1. Open several Mozilla windows ... I opened 5 windows and kept them clearly
identified by their button positions on the task bar ... Window 1 is left-most
and Window 5 is right-most.
2. Minimize windows 1, 2, 3, and 4.
3. Unminimize window 2.
4. Minimize window 5
5. Minimize window 2

Result: Window 5 restores not window 2 which I would have expected.

Window 5 is currently the last-created Mozilla window.

Further, if you open a window in another application before doing step 5, you
will of course succeed in minimizing window 2 and when you minimize that other
application's window, Mozilla Window 5 will restore ... again the current
last-created window.

Finally, if you close window 5 insted of minimizing it in Step 4, window 4
becomes the "current last-created" Mozilla window and behaves just as window 5
did when you minimize window 2 in Step 5. 

         Dale
I am using Build 2002020406 on Win2K SP1. I am also experiencing this bug,
though I've seen some other things that don't seem to have been mentioned.
Firstly, if you Open in New Tab instead of New Window, then (perhaps obviously)
you won't have multiple windows, so you'll constantly experience the bug. This
reduces the usefulness of the Open in Tab feature. Also Minimize All on the
taskbar (or Windows+m keyboard shortcut) will minimize the Mozilla app, but
restoring another app, then minimizing it, will cause Mozilla to spring up from
the taskbar Restored. Minimizing a Maximized Mozilla app will result in Mozilla
appearing Restored, not Maximized. 

Additionally, I can't always get this issue to occur. I am using the Classic
theme. Just this instant, I was not experiencing the bug, but I reproduced it
with the following sequence:
1. Minimize and Maximize at will, to verify it works.
2. Open a new Tab, type www.cnn.com in the URL field
3. Try to minimize while CNN is loading: Window auto-reappears as a Restored
window. 
4. Stop CNN.com page load.
5. Minimize bug persists. Click Maximize in Mozilla
6. Press Windows+m keyboard shortcut; everything minimizes successfully.
7. Click on non-Mozilla app on taskbar to restore (I had Outlook, Acrobat
Reader, and a terminal emulator, tried them all with the same effect)
8. non-Mozilla app restores, Mozilla stays minimized.
9. Minimize non-Mozilla app, it minimizes and Mozilla springs up on its own.
10. Closed the CNN tab, it does not help. 
11. Open a second Browser window (www.slashdot.org). The new window works
properly, but the original one still will not minimize.
12. Maximize both Mozilla windows. Switch to second window by clicking on taskbar. 
13. Close window with x in top-right corner.
14. Original window now minimizes properly.

Now, I repeated steps 1-9. Left the CNN.com tab open (no step 10). Opened a new
window as in step 11. Original window will not minimize. Here I deviate:
11.1: Maximize Window 1 (with 2 tabs, tab1 = this Bugzilla entry, tab2 =
partially loaded CNN.com)
11.2: Maximize Window 2 (slashdot.org)
11.3: Min Window one, it works. Click on Window 2 on taskbar, Min window 2, it
bounces back. Maximize both again.
11.4: Min window 2, it works. Click on Window 1 on taskbar, Min window 1. Window
2 bounces back. 

Now, the wierd part... wait 5 minutes while I type all this in. Try the windows
again... they both work! So, back to Step 11. While slashdot.org is loading in
Window 2, the restore bounceback happens faithfully. For some period after the
page appears to have completed, it also bounces back as described. After about
3-5 minutes, however, the behavior goes away and both windows minimize normally.

After doing these tests, I can open CNN.com in a tab and minimize works
properly, with either tab on top, even while CNN.com is loading. On testing the
multiple window sequence a third time, I find that the period of
bounceback/autorestore is shortened to perhaps 30 seconds. This is probably
because www.slashdot.org is in my cache now.

So, it's not exactly CONSTANT, but certainly irritating and definitely possible
to reproduce.
This sounds very much like a sticky flag causing the problem and the status
should be blocker not major.  This should not have been propogated into a
milestone release, letting it out just hands an even bigger stick to those
wanting to beat this development into the ground.
Is there more than just one instance of it happening on XP?  I am seeing it on
Win2k, but I don't use XP on anything.  One set of changes that happened in the
period concerns supporting XP drop down shadows and tabbing behaviour within the
native windowing code. This might have created a side-effect of stuttering the
message queue so that either a message is processed twice or one is missed entirely.

That feels sort of right as the behaviour is that a minimise becomes a set
focus, implied restore when there are no other windows raised on the desktop.
simon>
That feels sort of right as the behaviour is that a minimise becomes a set
focus, implied restore when there are no other windows raised on the desktop.
/simon>

Question: On WinNT4 (which I use), would that be cleared up by using the
Taskbar's context menu "Minimize All Windows" and yet NOT be cleared by using
the [Windows]-M keyboard shortcut?  This is what I am finding consistently on
WinNT4.

Observation: Comparing Tony's report in Comment #68 and my observations in
Comment #67, it looks like there may be a difference in bahavior for the
keyboard shortcut and the context menu command between WinNT4 and Win2K.  I
wonder if that's correct and, if so, why.

Dale
*** Bug 124353 has been marked as a duplicate of this bug. ***
Hmmm, for a while I thought that the changes to support XP window class
differences might be to blame because they rely on a failure to register the
Window to determine that XP isnt being used which just seems wrong to me.

Taking that out though doesn't make any difference at all.

I've noticed one other side-effect.  If the Mozilla window is the only one open
then the Resize event doesn't just get ignored the Size property on the Window
Class itself is switched off. It gets swtiched back on if there is more than one
window of any kind open.  This also points to some mucking about with the window
class.


The Resize problem only happens if the window has been maximised in between.
*** Bug 124414 has been marked as a duplicate of this bug. ***
after d/l of build 202020803
attempted to minimize when it was the only window open (THIS WORKS)
attempted to minimize when other windows were open     (THIS WORKS)
attempted to use show desktop.                         (THIS WORKS)
attempted to use WINKEY+M.                             (THIS WORKS)
attempted to use WINKEY+D.                             (THIS WORKS)
attempted to use WINKEY+SHIFT+M                        (THIS WORKS)
attempted to minimize multiple windows                 (THIS WORKS IN ALL WINDOWS)

BUG APPEARS TO BE CORRECTED FOR MY PLATFORM (WIN98SE)
2002020803, Win98: sorry... not fixed.  Still behaves exactly as before on my
system.  All the symptoms are still present:

only occurs if Mozilla is loaded with Classic theme
window pops back up when the last window on the desktop closes.
etc...
If Mozilla is the only un-minimized window (i.e. the only window open, or all
others are already minimized), when I try to minimize it, it appears to
minimize, then pops back up.  When other windows are open and not minimized it
seems to behave normally.  --Cheryl LeCompte 
*** Bug 124516 has been marked as a duplicate of this bug. ***
*** Bug 124511 has been marked as a duplicate of this bug. ***
QA: to help with seeing this problem:

on windows, turn on the display properties > effects > transition [set it to
fade effect]  

you will see that the browser is trying to minimize the window it gets the
minimize event, 

Behavior is that *the window itself doesn't change to get smaller to be gone*, 

so the window itself is not dropping from view as it should if it truely is
being minimized.  

Then Once the titlebar fade gets to the taskbar, it bounces right back from the
taskbar to the titlebar.  

So simon says: that there is a problem with window itself and possible flagging
problems..

does anyone have a build date where this worked in one build then was busted in
the next: that way we can check the checkin's to bonsai to get a clear view what
patches changed this for the worse.  

*I will look my self on my win2k*

dman84
Steven Bush in Comments 3-8 did some narrowing down the time of this bug's
appearance.  Specifically, from Comment #7:
 
sb> After further testing:

sb> v0.9.7+ 
sb> Builds 2002010508 and prior work
sb> Builds 2002010608 and later exhibit the problem

I think that's the time frame you're looking for dman84.

Good hunting.
 
    Dale
*** Bug 124580 has been marked as a duplicate of this bug. ***
QA:

I see jag's comment #14 in bonsai checkins for build 1/6, possible culprits as
jag noted hyatt's: bug 115750 and bug 118368 and bug 115759.

Next step is:

for anyone that builds moz, try backing out any of those patches in your local
build & rebuild.  Other than that.. 

I think everyone has covered the possible problems with this, both minimize
first window, other windows, last windows, etc.

and also setfocus/restore event is fired upon page content load, which maybe
another issue all together.

beyond that:

Hyatt is assigned to this, and needs to be targeted for milestone.



reporter of bug 116485 says that this triggers when changing theme
*** Bug 124759 has been marked as a duplicate of this bug. ***
This bug also appears in Win2k!
Minimizes and immedieatly maximizes again
*** Bug 124813 has been marked as a duplicate of this bug. ***
nsbeta1+ per nav triage team
Keywords: nsbeta1nsbeta1+
I just installed Build ID: 2002020406 onto a Win2K system and it is still
happening!  Hope you guys figure this one out soon because this is becoming
bothersome.
Why expect people that this problem is fixed when this bug is not marked "fixed" ?
*** Bug 125028 has been marked as a duplicate of this bug. ***
just loaded build 2002021203. again it appears to be corrected. 
This issue persists in 2002021203 on WinXP--having uninstalled previous version,
deleted the mozilla directory, and deleted the application data folder.

For those that complain about people saying that it _has not_ been corrected, I
suggest that is either because there are people saying it _has_ been corrected
and/or because it is one of the most visible and most annoying bugs currently in
Mozilla. One would hope that this is one of the highest priority bugs to be
fixed--yet it appears to have been pushed out from nsbeta1 to nsbeta1+.
I would say the most likely reason for strain of any sort in relation to this
bug is that it is almost impossible for all users on all platforms to uniformly
reproduce this bug.  Personally, I have noticed that it happens most often when
I attempt to minimize the very first window that loads when I start mozilla.  In
this instance, Mozilla is the only window that I have open.  I have quick launch
enabled, but I am not sure this has anything to do with the bug.  Another point
of note is that there is something else for focus to transfer to once the
browser is minimized, such as an explorer window or even the start menu (if it
has been in focus immediately before Mozilla) the bug does not reproduce.  
>> 
  Another point of note is that there is something else for focus to transfer to...
<<

This sentence should read "IF there is something else for focus to transfer to".

Apologies for not proofreading.

*** Bug 125089 has been marked as a duplicate of this bug. ***
Folks, this bug has not been 'pushed out'.  The nsbeta1 keyword is used to
nominate bugs (in Mozilla) that people think need to be fixed for Netscape's
next release. The nsbeta1+ keyword is used by the our triage teams to indicate
bugs we feel *must* be fixed by the next release.  Hopefully, this will make
mozilla1.0 too.
I can repeatedly reproduce the bug on Windows 2000 SP1, in build 2002020406, in 
exactly the sequence I described several comments up. I continue to have this 
issue happen constantly. 

Additionally, I've noticed that even when the bug goes away, trying to minimize 
while there is a page loading will re-trigger the bug.
Apologies for not having a record of the build involved. I installed it on two
Win2K machines in succession, the first didn't exhibit this bug but the second
installation did ...
just got build 2002021403. and the bug has still been squashed in win98se
build 2002021430. it's baaaaack. 
Same problem (last Moz window always pops-up back when no other window-even
different application- is on the desktop) in Win NT, SP6a. I suggest to change
the OS to "all Windows".
changing OS -> win98 to All, I see it on W2K, others see W98, W98SE.. WXP.

Simon, you noted nsWindow...

can you dig deeper in the code there.. check bonsai and bring up the version
numbers and what code changes exist.  Maybe that will give us a start to fix
this up.

-dennis
OS: Windows 98 → All
I already did that, but look at comment #21
*** Bug 125697 has been marked as a duplicate of this bug. ***
'All' means linux/mac/win32, not all windows.

Perhaps we could have less chatter. There is a problem, it's known to be a 
problem, it is scheduled to be fixed.

OS: All → Windows 98
*** Bug 125907 has been marked as a duplicate of this bug. ***
*** Bug 126098 has been marked as a duplicate of this bug. ***
*** Bug 126294 has been marked as a duplicate of this bug. ***
Summary: Browser window does not minimize → Browser window does not minimize (minimised window restores, won't stay minimised)
Whiteboard: [Hixie-P0][Hixie-1.0]
Someone asked if other people see it in XP.  I have seen it in XP on several
occasions.

I see LOTS of dups, lots of "still broken, and here are 27 ways to repeat it",
but no motion to fixing it.

I could not personally sanction releasing a "1.0" product with a bug this
annoying and common in it.  Is it really that hard to track down?  (I don't even
like having it be in a milestone.)
  For me, this bug happens reliably if the attempt is made immediately after
opening the browser. (Minimize every window on the desktop, launch to a single
new browser window, minimize.) After the browser has been open for a while the
problem seems to fix itself. I'm guessing that happens after focus memory is
changed to something other than the initial default (see below).
  Each top-level (browser) window has associated with it a few menu popup
windows. They're visible, but with size (0,0). As the last browser window is
minimized, Windows activates and focuses one of these "visible" menu popups. As
far as Windows is concerned, they're not children of their corresponding
browser: their parent is the desktop. So it's maybe reasonable that Windows
tries to activate one of them.
  The menu window seems to share its browser window's root focus controller. I
don't know this for certain, but that's what it looks like. So the root focus
controller's focus memory remembers the DOM window to which focus should be
restored -- the browser window -- and activates that window.
  We restore a window when it gets focus: script that wants to focus a window
also wants it to be visible. This code intersects that code path.
  I'm not ready to suggest a fix, just to increase this bug's signal to noise
ratio slightly. Does any of the above strike any useful bells?
*** Bug 126553 has been marked as a duplicate of this bug. ***
*** Bug 126616 has been marked as a duplicate of this bug. ***
*** Bug 126949 has been marked as a duplicate of this bug. ***
*** Bug 126967 has been marked as a duplicate of this bug. ***
My nightly build copy, Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+)
Gecko/20020221, the exclusive-window problem is still present.
The bug occurs in Win XP Pro, build 20020204.

However, for me it is possible to crash Mozilla using the minimize bug, I was
just wondering if anyone can reproduce this.

1. Start Mozilla in Classic theme.
2. Open a new window.
3. Minimize the new window.  On my system, the new window disappears showing the
original window.
4. Minimize the original window.  The new window should now reappear in
non-maximized mode.
5. In the new window, change the theme to Modern.
6. When the Modern theme is applied, try to change the theme back to Classic.

At this point my browser freezes and I get a message from XP telling me the
program is no longer responding.
*** Bug 127521 has been marked as a duplicate of this bug. ***
Not sure if anybody working on this has the following information.  If they
don't, I hope it's useful.

If I run:
    set MOZ_DATE=5 Jan 2002 5:00 PM PST
    nmake /f client.mak pull_all clobber_all build_all
then I get a build with the old minimize behavior.  If I run:
    set MOZ_DATE=5 Jan 2002 6:00 PM PST
    nmake /f client.mak pull_all clobber_all build_all
then I get a build with the aggressive un-minimize behavior.

Cvs diff'ing only turns up three changed files during this time period:
    X:\Dev>cvs -q diff -c -D "5 Jan 2002 5:00 PM PST" -D "5 Jan 2002 6:00 PM
PST" mozilla > diffs56.txt
    X:\Dev>egrep "RCS file|diff" diffs56.txt
    RCS file: /cvsroot/mozilla/gfx/src/windows/nsNativeThemeWin.cpp,v
    diff -c -r3.7 -r3.8
    RCS file: /cvsroot/mozilla/gfx/src/windows/nsNativeThemeWin.h,v
    diff -c -r3.4 -r3.5
    RCS file: /cvsroot/mozilla/themes/classic/global/win/textbox.css,v
    diff -c -r1.4 -r1.5

It'd be nice to get a band-aid on this minimize bug, so that people can
eventually get around to putting band-aids on the other minimize bugs.
danm: can you take this bug?
Same effect NT 4 (SP6a) in 0.98

While I've had this happen to me on occasion over the last few months, it's
suddenly, within the last few days, become a constant and highly annoying
occurrence.  Mozilla gets into a state where it absolutely refuses to stay down
when minimized, which is a major nuisance when I'm trying to minimize everything
to gain access to my desktop.  In the past it used to be possible to snap it out
of this state by focusing temporarily on some other window, now it's being much
more tenacious at remaining in this nasty state, and I can't figure out exactly
how to get it out of it, though it does sometimes manage to return to normal for
a while.
STOP SPAMMING THIS BUG PLEASE

It's a known bug, it's not fixed and the developer will work on it.
*** Bug 127895 has been marked as a duplicate of this bug. ***
*** Bug 127904 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0][Hixie-1.0] [driver:shaver]
Windows 2000, identical problem.
Looks as if it cannot load an flash-plugin and then stays on screen. Only if you
maximize another window the mozilla window will minimize.
I'm running build ID: 20022020406. I'm running WinNT v4.0 (4.00.1381).

I *think* I may have new information to offer: I can make the problem go away by
going to View->Show/Hide and turning *OFF* the Navigation Toolbar.

So, for me, the problem occurs when:

1) A Mozilla window is the *only* window displayed on the screen
2) That mozilla window has the "Navigation Toolbar" turned *ON*.

This is my first bugzilla report, so please be tolerant if I've done it badly.
And my intent is to provide new information, not spam the developers.

-- Tom S.
I also have to report that the bug crashed mozilla. When I try to close the
window in the "stuck-state" (restored, not resizeable).
I sometimes works when i maximize it before.
Based on comment 120 and comment 128, is there any chance that this has
something to do with the URL Bar having focus or not?
#131: Did that, got the error message, window flashed once (once!) and then
stopped flashing. 2002-02-27-03, Windows XP Pro.
Hey, I just found out how to turn this into a FEATURE --- "Auto Restore".

When the Mozilla window is in this special condition, and there are other
windows on the screen, the Mozilla window will minimize. But now, like a
jack-in-the-box, as soon as the the LAST other window is closed, up it pops --
AUTO RESTORE!

To demonstrate:

Open one other window (I used an outlook express window).
Open one Mozilla window.
Be sure that the navigation bar is turned ON.
Minimize the Mozilla window. It will stay down.
Now minimize the other window.

BOINGGGGGGGG! Up pops the Mozilla window, like an obedient servant.

(Build ID: 2002020406, WinNt 4.00.1381)
It's possible this problem is related to bug 109081 and 73995. Once the fix for
bug 109081 get checked in, the solution may consist to just disable the window
when you mimimize it using nsIBaseWindow::SetEnable. And don't forget to enable
it when you expand it again.
*** Bug 128569 has been marked as a duplicate of this bug. ***
I'm also having this problem. The windows/browser will not minimize. The pop 
back up in restored mode. -=critical=-
-- Kyle
This bug is misassigned.  Dan, can you help?

/be
Assignee: hyatt → danm
Status: ASSIGNED → NEW
*** Bug 128633 has been marked as a duplicate of this bug. ***
*** Bug 128650 has been marked as a duplicate of this bug. ***
*** Bug 128738 has been marked as a duplicate of this bug. ***
not gonna make 0.9.9 :(
No longer blocks: 122050
should this be in XPApps rather than XPtoolkit?
Click on Show desktop in win32. Now you can maximize the window, click on
minimize and it doesn't open up anymore.
*** Bug 129222 has been marked as a duplicate of this bug. ***
pulling 0.9.9 keyword per asa, adding mozilla1.0 hoping all regressions such as
this get looked at before 1.0 is cut.
Keywords: mozilla0.9.9mozilla1.0
Windows NT shows this behaviour, too!

Build ID 2002030508
After opening other windows it works(?)

In the Version 1 Month ago it worked.

Hermann
the bug# for the checkin mentioned in comment 120 is bug 115759
*** Bug 129271 has been marked as a duplicate of this bug. ***
*** Bug 129449 has been marked as a duplicate of this bug. ***
Clicking F11 to go to full screen mode causes this problem to disappear.
Probably because full screen mode uses a different toolbar and not the
Navigation Toolbar.

I am using nightly 2002030703 on Win 98.
*** Bug 126577 has been marked as a duplicate of this bug. ***
*** Bug 129673 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.0
I hate to jump the gun here, but I've been using 0.9.9 for a few hours now, and
I haven't encountered this problem.  Perhaps it was related to, and fixed by,
bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=122765">122765</a>?
No, it's still happening with today's build. It's just not quite as effortless
to reproduce as is sometimes implied.
*** Bug 130194 has been marked as a duplicate of this bug. ***
I am using 0.9.9 and it happens to me quite often.  It is really annoying. 
Everytime I minimize it keeps reopening the window.
It's a known problem, hence the bug is open.
There's no question that it's reproducible.

Adding "me too's" does not help anyone. 
You're spamming everyone CCed on this bug.
Unless you have anything new & RELEVANT that can help then, and only then, you
need to comment.
When I replaced skins/classic/global/textbox.css with the version from milestone
0.9.7, the problem goes away. (build 2002031104, win2k) - Does this work for
anyone else?

If so, hopefully this should help narrow the problem down, or at least put a
band-aid^H^H^H^H^H^H^H^H adhesive medical strip on it.
If that's right, based on comment 120 I'd be leaning towards this check-in of
textbox.css:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=textbox.css&filetype=match&who=hyatt%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F05%2F2002&maxdate=01%2F06%2F2002&cvsroot=%2Fcvsroot

All that did was add "-moz-appearance: textfield" to the textfield style.  Maybe
it has this effect when coupled with the changes to nsNativeThemeWin.cpp around
the same time.
Yes, backing out that line fixes the bug for me (win2k).

Not sure what it will do to gnome, winXP though...
Well, for WinXP it won't theme textfields anymore, which obviously isn't
acceptable.  It's got to be something in the actual theming code.  Is that all
in nsNativeThemeWin.cpp?  That still makes sense based on the observation in
comment 120.

I've looked through the file and nothing obvious sticks out.
Dean, you rock -- hyatt, bryner, danm, any ideas based on the id'd checkin?

/be
*** Bug 130490 has been marked as a duplicate of this bug. ***
*** Bug 130596 has been marked as a duplicate of this bug. ***
Any of these individual patches will convince the browser to stay minimised,
though each breaks something else. The first one is Dean's interesting find.
Surprisingly, removing the popup menu from the urlbar doesn't help, which makes
me doubt my comment 112. I'm still inclined to think the real fix will have
something to do with focus controllers, but these little tidbits are
interesting.
a small but perhaps interesting observation from NT 4.0:
If you change the taskbar-settings (f. ex. enable/disable "automatically
background") while mozilla (0.9.9) is running, afterwards the problem has
vanished. But just as long as you don't close mozilla.
After restarting mozilla, the problem is back. I tried it out several times, to
verify these "interferences". Hope it helps somehow.
FWIW, I noticed that on NT I can use the taskbar's "minimize all windows" and
everything minimizes and stays that way even if one of the windows had been
bouncing previously.  (I usually hit this problem with the mail compose window
only.)
This is ridiculous!. Tried 0.99 and it still does the same thing. I suggest you 
postpone your launch date for April till sometime in December. Because if a 
simple thing like this doesn't get fixed. Than you will be laughed off the 
planet. Mozilla 0.99 is worse than Netscape 6.0 was. Windows XP -Mozilla 0.99 
build. So far IE 6.0, Opera 6.0, and Netscape 6.2.1 are way better and way more 
stable than Mozilla 0.99. They work as they should!. I guess this is why 
Microsoft doesn't want to go to open source. All this time to develop a browser 
and it still doesn't even work right.  
*** Bug 130770 has been marked as a duplicate of this bug. ***
Bug appears to be fixed on this end with todays 03-14-02 release.

Mozilla 0.9.9+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020314

... I'll do some more checks later -- I had WinMX running during this test.
Update:

Bug still exist -- However, it occurs less frequent and appears quite random.

More testers needed for this version: 20020314  
Build 2002031403 - no cigar.  It is still just as frequent as it was before. 
Thanks for trying - keep up the good work!  I'll take Mozilla in its current
state ANYDAY over that **** product Microsoft calls a browser!
*** Bug 130955 has been marked as a duplicate of this bug. ***
*** Bug 131104 has been marked as a duplicate of this bug. ***
*** Bug 131114 has been marked as a duplicate of this bug. ***
0.9.8 and 0.9.9 both have this problem for me, 0.9.7 works fine... XP pro. This
is a very frustrating bug.. Does it have something to do with the auto restore
when the page is loaded feature? Personally i find that feature completely
annoying and would love to see a switch that says, if your minimized, stay
minimized!
0.9.8 and 0.9.9 both have this problem for me, 0.9.7 works fine... XP pro. This
is a very frustrating bug.. Does it have something to do with the auto restore
when the page is loaded feature? Personally i find that feature completely
annoying and would love to see a switch that says, if your minimized, stay
minimized!
we are at 0.9.9 and still can't get the minimize bug fixed
what at shame
As I said in my duplicate bug: It only happens when I have only one Mozilla
window open. Usually when I have 2 or more windows open, it parks in the taskbar
without problems. This is for all windows.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020314
I only had the same problem with the 20020306 version. Any version before that
(all 0.9.8+) didn't have this problem.

My apologies to the Mozilla developers for my commentary earlier about the
minimize bug. I know you are all working **** this browser and I should be a
little more patient. I strongly support the Mozilla browser and Netscape over
IE, with bugs or no bugs. 

Jorge Vargas
*** Bug 131240 has been marked as a duplicate of this bug. ***
*** Bug 131310 has been marked as a duplicate of this bug. ***
*** Bug 124551 has been marked as a duplicate of this bug. ***
*** Bug 131385 has been marked as a duplicate of this bug. ***
In Build ID 2002031708 on NT 4 I still see this problem. I have observed that
using the "minimize all windows" option in the taskbar removes the problem from
the windows that exist, but not from windows created later.  The problem is
removed from all windows - both minimized and not minimized ones.
*** Bug 131786 has been marked as a duplicate of this bug. ***
*** Bug 131920 has been marked as a duplicate of this bug. ***
57 duplicates.. 
*** Bug 132212 has been marked as a duplicate of this bug. ***
Just summarizing bug for those who are new to the party and haven't read.. 

These are the significant comments to read as of Now:

comment 7, comment 54, comment 55.. comment 81, comment 112, comment 120,
comment 132, comment 158 thru comment 164.

everything else we know is that this happens on all win32 platforms since build
1/5/2002, using the classic theme, with various problems and reproducable steps.

and with that: read comment #124.
I get pretty much the same behaviour as described by everybody else, but I am
using the Modern theme. It is possible that there are two different but similar
bugs...
*** Bug 132285 has been marked as a duplicate of this bug. ***
I am getting the same behavior on both themes.  My guess would be that this bug
is theme-independent (of course, I don't know anything about how the themes are
programmed.)
I do not get the same behaviour in both themes.  Minimize works fine for me in
the modern theme.
I've been experiencing the problem with every theme.
*** Bug 132535 has been marked as a duplicate of this bug. ***
*** Bug 46988 has been marked as a duplicate of this bug. ***
Duping an old bug (bug 46988), reopened today, gave this one additional 18 dups.
Very clever :-(
I'm just making a comment in this bug because it's such a fun spam machine
and I'm one of the few people on this planet who haven't been taking advantage
of that.
  Oh and yes, this patch seems to fix the bug. But it's quite preliminary --
more a notification that people *are* working on the damn thing, so if I
haven't already said something, hush, you muskies.
  The bug is caused by an independent, unowned top-level window associated with
the browser. It's a menu popup widget; I believe it's the one for the popup
history menu in the URLbar, though other evidence seems to refute that. Anyway
when the user minimises the browser window, the OS deactivates it and finds
some other window to activate. Under the right conditions the next activatable
window in line is this window that belongs to the popup. That's unfortunate.
Mozilla realizes this window actually belongs to the browser, so it transfers
the activation (and focus) to the browser window. We have other code that
restores a minimised window when it gets focus. So the recently minimised
browser pops back open.
  The above patch most likely sidesteps this problem by making the popup window
owned by the browser window. Windows OS should then no longer consider it when
looking for the next window to activate as the browser is minimised. And it
works.
  And so far it seems to work flawlessly. I'm very surprised. I was expecting
problems like clipping of popup menus to the browser window, or mishandling of
events as the bubble out of the menu. Hmmmm. Still looking.
*** Bug 132655 has been marked as a duplicate of this bug. ***
I can confirm that after I wrote my last post, that Modern wont minimize.. if:

A) mozilla is the only program open
B) only one browser window has been opened thus far
C) you just View>Apply Theme > Modern.

Modern will then refuse to minimize that only window on your desktop.
If I follow the steps from dman84, my Mozilla will minimize.
I applied the Modern theme and could minimize the window right away.
I then applied the Classic theme again, minimized and up it went immediately,
restoring to a halfsize window.

I retried this 3 times. I guess my problem lies with the Classic theme.
So I will use the Modern theme for the next days, see if it starts degrading as
well.
Attached patch serious attempt at a fix (obsolete) — Splinter Review
I'll need help testing event processing with this patch, but it seems good.
I'm also experimenting with another more direct route, but it doesn't work
nearly as well and is quickly getting very ugly. This one's, like, elegant and
it works.
  Note this patch gives popup windows a parent, if applicable. They originally
had a parent, but that link was cut to fix bug 13644 and bug 15312. But I
believe this patch doesn't regress those bugs.
Attachment #75454 - Attachment is obsolete: true
danm: take a read of dales' comment #67.  focusing.  

I think whether or not modern will not minimize is determined by platform and
build id also..  cuz I do see this problem if I say have opened two tabs and do
those steps I had outlined.  Which to me it is starting to sound like this is
bigger than just themes.
*** Bug 133531 has been marked as a duplicate of this bug. ***
*** Bug 133531 has been marked as a duplicate of this bug. ***
*** Bug 133594 has been marked as a duplicate of this bug. ***
Comment on attachment 75659 [details] [diff] [review]
serious attempt at a fix

r=kmcclusk@netscape.com. The patch does not cause any ill effects when dropping
down comboboxes, the URL bar, mousing over menus, or displaying popups
Attachment #75659 - Flags: review+
Comment on attachment 75659 [details] [diff] [review]
serious attempt at a fix

sr=hyatt.  Test thoroughly.
Attachment #75659 - Flags: superreview+
Note to approval types about Hyatt's admonishment to test this thoroughly: I've
been running with it for a while and seen no problems. I've looked for event
delivery problems like mistaken positional offsets in highlighting or
mouseclicking; keyboard navigation; that sort of thing. None have showed up.
Also I believe doesn't regress either of the two bugs for which the null parent
was first created (bug 13644 and bug 15313). So, seems good.
wanted for 1.0
Keywords: mozilla1.0mozilla1.0+
Comment on attachment 75659 [details] [diff] [review]
serious attempt at a fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75659 - Flags: approval+
*** Bug 133988 has been marked as a duplicate of this bug. ***
Patch just went in. I'm closing this spamfest with a tear in my eye. Here's
hoping that everyone was really having the same problem I saw, and that all 60+
duplicate bugs were really the same thing. Lord help us.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 134088 has been marked as a duplicate of this bug. ***
I feel so sad.. my favorite bug has been fixed! :(

After 53 votes and 80 dupes, I guess it was coming.
Wow... I'm all choked up. After all this time, I might never get spammed by 
this bug again.

I feel like we've grown so close...

I'll miss you all!

<sniff sniff>
<choke>
Waaaaahh! <sob sob sob>
when should we see the bug fix for this?
I have build 2002032821 that still has the problem... with classic or modern theme.
After applying a theme, the problem always show up.

I am on WindowsXP Pro...
No comment seems to actually confirm that it has been checked in, and I couldn't
find this bug number in the checkins of the previous 60 hours, so it looks like
it has yet to be checked in.
3.409danm%netscape.comMar 28 13:25  tie popup widgets to their parent browser
window (really, stop not tying them) so the OS won't try to activate them when
the browser is minimized. bug 120155 r=hyatt,kmcclusk a=asa
it appears to be working correctly in build 3-29-16 win2k.  Thanks Danm.
ok, hate to spam you guys but.. 

damn: 

I found that while minimize does work properly.. I see 2 things so far with this
checkin patch.. maybe we should address differently in a new bug.

1) I open Tools: Download Manager from the browser window, wait a few seconds
and it goes behind the browser window.

2) click compose from mail/news window, wait a few seconds and it will go behind
the Mail/News window.
You're wrong. I tried what you said, and windows stayed on top !

Build 2002032916.
I see, it was doing it on my clean formated windows 2000, with a new profile.. I
also used it on 3-27 profile too.. but now it is not doing that.. so I dont
understand.  If it stays ok, thats good then.  Otherwise if I see it more then
I'll open a new bug at some point.
What happened for me several times yesterday was the following:

1. I'm browsing as usual.
2. The alert comes up in the bottom right.
3. I click on an alert link.
4. The mail window comes up with the proper folder as usual, BUT
5. The previous navigator window gets focus again.

I suppose this has to do with the patch too, right?
Another issue occurs with 2002032916 on Windows 98 when you open a link to a
large web page in a new window, such as 
http://www.washingtonpost.com/wp-dyn/articles/A37019-2002Mar29.html   (but you
might need to pick a bigger one if you have a lot of bandwidth), then switch the
focus to the first window before it finishes loading. After the second window
finishes loading, the second window takes the focus. The second window shouldn't
take the focus in that situation.

Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I think comment 255 is a different bug... there are actually several bugs
involving the improper gaining or losing of focus.  Bug 88810 is a tracking bug
for a few of them.
It could be. The problem I described started happening with the 2002032903
build, and it also occurs on the 2002032916 build. That's why I thought it was
probably this bug. 
Blocks: 88810
marking fixed again.
This could be a regression from this bug but I opened already a new one.
(bug 134317)
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
  Turns out there are some focus problems with my fix for this bug. They're
being tracked in another bug. I have a new hobby: fixing those regressions
without regressing this one. I'll leave it as an exercise for those truly
interested to find the new bug; much as I appreciate the spamfest this bug
became, I'd just as soon keep the other one a little more manageable.
  Meanwhile I'm surprised such a contentious bug as this has been reopened and
reclosed only once so far. Capital!
*** Bug 134873 has been marked as a duplicate of this bug. ***
*** Bug 135015 has been marked as a duplicate of this bug. ***
this seems to be also seen in bug 105225 comment 49.  which is also seperate
than bug 105225 problem.. 
I'm removing this release note item for this bug from the Mozilla 1.0 and
future versions of the release notes because this bug is marked fixed.

Mail me if you think this item should be re-added.
*** Bug 135893 has been marked as a duplicate of this bug. ***
*** Bug 135952 has been marked as a duplicate of this bug. ***
*** Bug 136089 has been marked as a duplicate of this bug. ***
This patch in comment 202 caused bug 134317 and bug 135528. It's been backed
out. Reopening. Woo hoo!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
But those two bugs aren't half as annoying as this one. I can live with those two.

I suggest you keep your patch in the 1.0 branch, but remove it from the trunk
pending a better patch. I'd rather have the two regressions in RC1 than this one.

I don't think there will be as much rejoicing with the resolution of those two
regressions as there was for this one when your patch was accepted.
It is not open for debate, particularly in this bug report.

If you wish, you may raise the issue with drivers@mozilla.org, but I think 
you should consider the scope of the other two bugs more closely and compare it 
to the scope of this bug before you do so.

Thanks.
Re-adding relnote keyword as per comment 233.
Keywords: relnote
*** Bug 136620 has been marked as a duplicate of this bug. ***
I think there is a kind of work around.

Open 2 navigator windows. Minimize one, it doesn't go back.

Close the other, bug is visible.

Hope it helps !
Since we evidently can't twiddle the parents to avoid getting the focus event 
in the first place, can we just eat the SETFOCUS before anything gets a chance 
to activate?  Either in the focus controller of the hidden windows before they 
bubble it up to the main window or in the main window itself.  Will this affect 
other applications if a Mozilla hidden window is in front of another 
application's window in the focus order and Mozilla eats the event without 
doing anything?
*** Bug 136694 has been marked as a duplicate of this bug. ***
upping to blocker severity. this is darn nasty.
Severity: major → blocker
Keywords: adt1.0.0
*** Bug 136726 has been marked as a duplicate of this bug. ***
*** Bug 136710 has been marked as a duplicate of this bug. ***
*** Bug 136752 has been marked as a duplicate of this bug. ***
The most recent patch should be obsoleted, since it caused two major
regressionsd. Hence, the reason Dan backed it out. Removing adt1.0.0 nomination.
Pls renominate when there is a new patch, that has been reviewed, and tested on
the trunk.
Keywords: adt1.0.0
Whiteboard: [Hixie-P0][Hixie-1.0] [driver:shaver] → [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1]
Noticed that with the bugfixed version (0.99+) that revived two earlier bugs, when minimized, it always appears as the second tile on the Windows98SE task list (brought up using alt-tab).
I'm observing the same behaviour as Steven Bush on 2002-01-15 23:50 on version
0.9.9 (2002031104).
Attachment #75659 - Attachment is obsolete: true
Attachment #75659 - Flags: needs-work+
Windows 2000 PRO, behavior is as follows:

- Browser window as only window visible (i.e., only non-minimized window),
clicking minimize widget will cause the window to "bounce"; it tries to
minimize, and as soon as the shrinking bounds box "hits" the taskbar, it
immediately restores.

- Other windows non-minimized, clicking minimize causes expected behavior.
However, when the last non-Mozilla non-minimized window is minimized, the
Mozilla window pops back up out of the taskbar.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
(Talkback enabled)
I need to call attention to Win32 trunk Build 2002041103.  Minimization is
WORKING in this build while not working as described many times in this bug for
all the build leading up to this one.

From the discussion, I see no evidence of changes being done to address this bug. 

So what happened yesterday to "fix" (aka "suppress") this bug?????????

Dale
*** Bug 137099 has been marked as a duplicate of this bug. ***
*** Bug 137090 has been marked as a duplicate of this bug. ***
trunk build 2002041203 on Win98SE

Right after startup from quick launch -> Does minimize
After click url bar -> Doesn't minimize

Something has been changed?
For what it worth - the latest nightly (2002041203) on Windows 2k - minimizes
windows properly for me in Modern.  It doesn't (the buggers pop right back up)
in Classic.  It's repeatable, and the behavior persists after reboots.
*** Bug 137368 has been marked as a duplicate of this bug. ***
*** Bug 137387 has been marked as a duplicate of this bug. ***
Build Id: 2002041408
Mozilla in Full Screen mode.
          -------------------
When I try to minimize the winow in full screen mode, the window bounces back to
full screen mode if it is the last open window on the desktop. Further
investigation indicates that clicking the minimize button two/three times makes
the window minimize.

Using the Alt+Space (window) menu's Minimize menu item has no effect on the
window, it stays maximized on the desktop (it does appear to bounce back in place)

Theme: Classic
OS: Windows XP Professional
Reproducibility: always
*** Bug 137546 has been marked as a duplicate of this bug. ***
*** Bug 137869 has been marked as a duplicate of this bug. ***
*** Bug 138010 has been marked as a duplicate of this bug. ***
could someone please write up an item for this bug to add to the release notes
and add it to the 1.0 release notes bug 133795. thanks
I had written a release note and then noticed Simon's synopsis. To avoid
spamming that bug, I propose here the following additions/clarifications to his
listed work arounds: 

[Remove the automagically sentence (last sentence, 2d paragraph) because this
restates the problem and intermixes the workaround]

[Replace current workarounds summary with the following:]

* The best workaround is to change to the Modern theme and restart Mozilla. 
* Other workarounds include:
a.) opening multiple windows and/or tabs within Mozilla prior to minimizing it;
b.) ensuring that at least one other program is visible on your Windows Desktop
when you minimize Mozilla; or
c.) right-clicking on the Windows Taskbar and selecting Minimize All (Show the
Desktop if you are using Windows XP).

[It's my understanding that using the bug does not appear if you use Modern
theme at all times during a session, hence the instructions to restart the browser.]
Am I to understand that writing release notes about this bug is an indication 
that it won't be fixed in v1.0? 

That can't be true, because blatant glaring UI errors like this don't belong in 
v1.0, right?

Firstly, my experience is that using the modern theme is not a reliable 
workaround, nor are any of the other ones suggested here. There are several 
ways to temporarily 'dodge' the bug, but that's not a workaround.

Secondly, why not just remove the classic theme altogether? Make Modern the 
default or something.
Tony Dye, I totally agree with your opinion.  Classic theme has no reason to
exist. And furthermore, by "Classic", N4 skin isn't that classic; Mozaic's skin
is more appropriate indeed.  "Modern" should really be the default, and another
nice skin should be provided at the same time (or people won't know it's
possible to change skin that easily).
I'm not warm and fuzzy about dropping Classic... personally, I find Modern to be
hideous.  Little Mozilla doesn't look bad, but I haven't tried it against the
Latest build.  I'm sure there are others who dislike Classic.

But why should a skin impact this bug?  Has the underlying problem with Classic,
which may or may not exist in Modern, been identified?  I don't see how the
image inside a button or the color of a border should make such a difference.

Of course I'm alread over my head, but I suspect that this bug is related, deep
down, to the "zombies" that plagued Netscape releases right through 6.2... the
Mozilla (Netscape) window management tricks, with hidden windows and all, put
too much of a strain on the underlying MS code.  I'd rather lose the ability to
close the first browser window while leaving the program open, which strikes me
as the major advantage of the scheme.
I have found the the only reliable workarounds listed in Commant 265 are:
1.  Use Modern Theme
2.  Right-click the Taskbar and use Minimize All Windows/Show Desktop
and one other
3.  Toggle Full Screen mode (F11) on and off or vice versa

These methods have never failed me since I or someone else discovered them.  I
run on WinNT4 (if that is a factor).

I have found that multiple Mozilla windows does NOT fix the problem since you
can never minimize all windows without using method 2 or 3.
The problem is similar with having anther application's window open in order to
let you minimize the Mozilla window(s) ... not desireable either.

I would characterize the multiple window options as something other than
'workarounds'.  Some may find their method of working makes them useful, so
they'd need to be aware of them.

Later ...
             Dale
This bug isn't just a Classic problem. I can get it on Modern, as well, and it
is fairly reproducable. Click on a link to a page such as
http://bugzilla.mozilla.org/showvotes.cgi
When the url bar changes to show the correct location, but before the page
renders, minimize the window. When the page renders, it also restores itself.
This happens on pretty much all pages, but the longer the time it takes to
render after the URL bar updates, the easier it is to reproduce it (for fairly
obvious reasons).
Is it possible that you (comment #270) are using a slightly older build and are
seeing bug #134317 instead?  The symptoms you are describing sound similar to
that bug (which was caused apparently by the earlier attempt at a fix for this
bug).  In buildID 2002041203 (win98, modern theme), I cannot duplicate the
symptoms you are seeing.
I'm running Build ID 2002041803 with Modern theme, but on Windows 2000. It is
very reproducible for me, anyways. The timing is a bit tricky, though.
*** Bug 138267 has been marked as a duplicate of this bug. ***
*** Bug 138268 has been marked as a duplicate of this bug. ***
Removing relnote keyword. We are not releasing this defect.
Keywords: relnote
Windows XP, Classic and Modern themes, RC1 I just downloaded, the very first 
time I opened the browser to give it a try, it refused to minimize.. after 
hitting F11 about 5 or 6 times then it finally minimized.

In modern them it took a few minutes of gonig to web pages before it won't 
minimize but it finally happened there..

I have completely wiped clean the mozilla directory, and the application 
directory for Mozilla.. I have tried this on Windows XP, Home, Pro, and Windows 
ME...

Good luck, looks like this is going to be a bugger and a half to fix.
latest summary of events:

well just in case you are new; again, please read comment #189...

its in RC1, and the trunk.. all windows versions..  on RC1 release notes.

if you can help to fix this .. the behavior hasn't really changed since it
started appearing.  See comment #209 for info on the patch that had been created.
*** Bug 138469 has been marked as a duplicate of this bug. ***
*** Bug 138575 has been marked as a duplicate of this bug. ***
Take three: This bug is caused by a menu window erroneously identifying itself
as an independent top-level window (see comment 198). My last attempted patch
made all menu windows be not independent and had bad side effects. This patch
explicitly hides the offending window when it's not, errr, visible. It's
working for me so far. Wants more testing.

This kind of fix acknowledges we have a general problem: our menu popup widgets
are independent, top-level windows and object greatly to being anything but.
This means you have to take some care using them. I haven't found a systemic
fix for the general problem that doesn't cause other problems. On the other
hand, this patch takes care of all known (by me, anyway) problematic uses of
the menu widget in our front end.
Comment on attachment 80085 [details] [diff] [review]
keep the offending window invisible when it's not being shown

sr=ben@netscape.com
*** Bug 138674 has been marked as a duplicate of this bug. ***
*** Bug 138778 has been marked as a duplicate of this bug. ***
*** Bug 138771 has been marked as a duplicate of this bug. ***
*** Bug 136308 has been marked as a duplicate of this bug. ***
In reply to comment #268:
This isn't the only bug where a particular skin is the cause of a bug.  It's
unbelievable and unthinkable, but it's true!  Other examples are bug 77285 and
bug 76126.
*** Bug 138914 has been marked as a duplicate of this bug. ***
Build: 2002041711
OS: Win XP Pro

Not sure how much this may help, but I didn't see anyone else mention it.
When the browser is exhibiting the minimize problem, typing any character into
the URL bar will cause minimize to work temporarily.  Once a link in the page is
clicked, and the URL is set to the new page by the browser, the minimize problem
returns (this is assuming you haven't used any of the tricks to "fix" the
minimize problem).
*** Bug 139267 has been marked as a duplicate of this bug. ***
*** Bug 139247 has been marked as a duplicate of this bug. ***
*** Bug 139513 has been marked as a duplicate of this bug. ***
*** Bug 139534 has been marked as a duplicate of this bug. ***
Is this patch ready to go into the trunk?  If it is I think you should land it
there and we should see if it works out.  It's getting late for beta so if this
works we may have to take this for rtm.
*** Bug 139652 has been marked as a duplicate of this bug. ***
Seems to happen when more than 1 Mozilla window is open at the same time
For me, it happens even if I start (on NT4) only one window (empty)
Same patch and effect as in comment 280 but this version doesn't step on the
possibly problematic "style" attribute. Oh, so *close* to 300 comments in this
bug!
Attachment #80085 - Attachment is obsolete: true
I'll try and play with this patch tomorrow.  I didn't see any problems with the 
last patch but I'll just assume there is some good reason to avoid style here.  
I wasn't seeing any of the regressions caused by the original patch and the 
evil focus bounce didn't happen.  Hopefully this can get on the trunk soon so 
lots of people can play with it and spam this bug.
Comment on attachment 80811 [details] [diff] [review]
keep the offending window mostly invisible redux

r=bryner
Attachment #80811 - Flags: review+
Comment on attachment 80811 [details] [diff] [review]
keep the offending window mostly invisible redux

sr=hyatt
Attachment #80811 - Flags: superreview+
Comment on attachment 80811 [details] [diff] [review]
keep the offending window mostly invisible redux

a=scc for checkin on the trunk.  This is a really important fix that I'd like
to see on the branch as soon as possible.  Let's bake it on the trunk a little
and then you'll get your a= for the branch.
Attachment #80811 - Flags: approval+
Changing to [adt1 rtm].  Let's let this bake on the trunk and see if we can take
this for rtm.
Whiteboard: [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1] → [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1 rtm]
*** Bug 139985 has been marked as a duplicate of this bug. ***
*** Bug 140033 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
Keywords: adt1.0.0
Whiteboard: [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1 rtm] → [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1 rtm][fixed on trunk]
*** Bug 133594 has been marked as a duplicate of this bug. ***
  Woo hoo! Count 'em! Today's requisite two new duplicate bugs (together with
the old one I just re-closed after its filer reopened it because he thought this
bug was too long) are the 99th and the 100th bugs closed as duplicates of this
one. What do I win?
  Oh yeah. It's fixed. Again I'm closing this bug, half hoping to be able to
reopen it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
works for me in today's trunk builds; I've been running with this patch on 
windows for several days, in typical use and have not noted any regressions
in browser/mailnews. I cannot reproduce the "won't-minimize" bug that this 
patch addresses with today's trunk-gmake build on win32. I have checked out 
the autocomplete widget in mailnews and urlbar on linux, and will be looking 
at today's mac builds in one moment. If no problems there, then I will be 
marking this verified shortly.
there's a problem with autocomplete on mac os/9. 
with both trunk-04/25 builds for OSX and OS9, the urlbar autocomplete widget
does not present the popup list of matching choices :-/ Oh, the humanity.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
John, just a quicky: are your comments about autocomplete are to be for bug 78270?
In a word, no.
Comment 32 for Bug 134317 still applies with build 2002042510.

Type in a url, minimise while page is loading and on completion of page load the
window pops back up.  Should this be a seperate bug?
From comment 312 :-
>>Type in a url, minimise while page is loading and on completion of page load the
>>window pops back up.  Should this be a seperate bug?

That has always happened.  I thought it was meant to be.  It would seem desirable.
>That has always happened.  I thought it was meant to be.  It would seem desirable.

Not to me...  I minimised the window because I didn't want to see it at that
time.  For it to pop up when it has been minimised is plain wrong.

On the positive side, that's the only window popping up bug I'm seeing.
*** Bug 140304 has been marked as a duplicate of this bug. ***
The original bug (window *immediately* pops-up after minimizing it, even for
non-loading pages) seems to be fixed. Some focus problems that lead to window
un-minimizing (after or during page loading) were discussed in bug 72651, after
fixing of that bug.  It has nothing to do with this bug. Maybe someone should
file a new one.
The "focus stealing and restoring windows on page load" bug has been around
since forever.
I think it was the reason I got a bugzilla account in the first place.

Many, many bugs have been filed on that behavior; some of which were resolved
dups, others resolved fixed.  A small list:
bug 77675, bug 105225, bug 97067, and bug 72651.

I wrote comm. 3 in bug 72651
(http://bugzilla.mozilla.org/show_bug.cgi?id=72651#c3) that pointed out several
other instances of this bug.

Is there an open bug describing this particular problem at this point?
*** Bug 140335 has been marked as a duplicate of this bug. ***
I was able to send multiple mails in various ways last night, fix does not seem
to impact ability to compose e-mail.
John: you commented about problems with Mac. Can you clarify? Is this because of
the fix? It's unclear to me based on your comment here.
The problem with restoring minimized windows on page load which was in comment
270 and http://bugzilla.mozilla.org/show_bug.cgi?id=134317#c32 is definitely
still happening in Build 2002042603 on Win2K. I'm not sure if it really belongs
with this bug, though. The summary is close, but the description only refers to
problems with minimizing the window in the firsts place. The only other open bug
I have found that is vaguely related is Mac OS X specific (so far) and has to do
with focus, not minimization.
The behaviour I see causes minimized windows to restore, but does not cause a
non-minimized window to get focus (which differentiates the bug from other
similar candidates). I don't see this on windows that are minimized immediately
after clicking the link or menu item. It has to be later. As I mentioned in the
linked comments, if you wait for the URL bar to update with the url, and THEN
minimize, it seems to be quite easy to duplicate it.
After doing some more testing, when the status bar message changes from "sending
request..." to "transferring data..." appears to be the time to minimize the
window. This works on URLS typed into the URL bar as well.
John, I think the Mac autocomplete problems you are seeing is
http://bugzilla.mozilla.org/show_bug.cgi?id=126480.

adding adt1.0.0+.  Please check this into the branch as soon as possible and add
the fixed1.0.0 keyword.
Keywords: adt1.0.0adt1.0.0+
noting that scc approved this on 2002-04-24 16:29:34
a=scc
Comment on attachment 80811 [details] [diff] [review]
keep the offending window mostly invisible redux

To clarify (I just discussed this with Asa), this is drivers approval for the
*branch* and we do want it on the branch so that it can get tested.
Using build 2002-04-26-06 (1.0-branch) on WinNT, the browser window still
refuses to stay minimized if there are no other windows open.  AND, as a new
regression, if you have one Mozilla window minimized successfully (because
another Windows app is open), when you minimize the other app, Mozilla unminimizes.
Seen this on 2000 as well.  Minimizing causes a bouncing effect (minimizes then
restores.)
Forgot to mention this is on class skin, Win 2000 and RC1 build 2002041711
We do not need any more comments here confirming that this happens on the
branch.  The fix has not landed on the branch yet.  Please do not spam the 146
people who get mail from this bug unless you really have something important to say.
re: comment 322, I think the problem John sees in comment 309 is legitimate.
In my own testing I don't really see bug 126480, and the autocomplete widget
appears or doesn't as you swap my previous patch in and out. This sucks. Hey
bug, I pretend to like you, but I'm just kidding.
  This seems like some deep-seated bug in Macintosh widget visibility code.
While I go poke around and try to figure out what the heck causes that, I
present the attached patch, which hack hack hacks the problem away. Consider it
for 1.0/beta/shipping! At least everything looks fixed with these changes.
I own most of the relevant focus stealing bugs. I'm watching. I have patches,
but finding time to finish them is difficult. Look at my 1.0 list if you want to
try some of them.
Just a minor quibble: from a safety standpoint, wouldn't it be better to not 
have the patch in by default and hacked in under windows rather than to have 
the patch in by default and hacked out under mac?
Please remove me from the Cc: list for this bug.  My email addres is
joeortiz@yahoo.com.  Thanks.

JLO
*** Bug 140587 has been marked as a duplicate of this bug. ***
Comment on attachment 81216 [details] [diff] [review]
hack the mac to work around a problem caused by the previous patch

Hmmm... It has the proper smell of a dirty hack...

You could prevent duplicating the jar.mn by creating a separate mac dir with a
two liner jar.mn that specifies an override rule for that one file (which would
still need to be duplicated), but that's already way too much work for such an
ugly hack, so sr=jag
Attachment #81216 - Flags: superreview+
*** Bug 140761 has been marked as a duplicate of this bug. ***
*** Bug 140753 has been marked as a duplicate of this bug. ***
fwiw, this won't work on mach-o builds.
Found a case where it's still not fixed:

1) Start with no windows open
2) Open browser and click on location bar
3) Type "www" or some other fragment that will trigger autocomplete dropdown
4) Open a new mozilla window using keyboard shortcut (Ctrl-1, Ctrl-2, Ctrl-E, 
Ctrl-M, Ctrl-N, etc.)
5) Autocomplete should dissapear and new window opens
6) Close or minimize new window
7) Minimize original window
8) bounce!

100% reproducible with hand-patched build and with 0428 trunk build.  And I'm 
not just saying this to make danm cry.  Looks like there are other code paths 
for closing autocomplete that need the |hidden| attribute change.
*** Bug 140973 has been marked as a duplicate of this bug. ***
Dan, does this need further reviews for the mac work around? We need to get this
in ASAP. Can you post a status here? Thanks.
*** Bug 140976 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P0][Hixie-1.0] [driver:shaver] [ADT1 rtm][fixed on trunk] → [Hixie-P0][Hixie-1.0] [driver:asa] [ADT1 rtm][fixed on trunk]
Better version of the Mac hack. As ac's comment 331 suggests, this patch
changes only the Windows autocomplete.css file. This will fix the mach-o
problem Brian mentions in comment 337. My plan is to make this the permanent
fix on the 1.0 branch, and go for a real solution for the Mac on the trunk. And
yes, I see the problem pointed out in ac's comment 338. Yargh. Yargh! I'll look
into that, too, but at this point...
Attachment #81216 - Attachment is obsolete: true
Comment on attachment 81630 [details] [diff] [review]
1.0 branch version: keep the offending window mostly invisible, but only on Windows

sr=jag (branch only, right?)
Attachment #81630 - Flags: superreview+
I verified that this occurs under both Windows 2000 and Windows 98.  Once it
starts happening, it occurs repeatedly, but until then, it doesn't occur at all.
 It seems to happen on about 20% of starts for me, under both 2000 and 98.
I believe this bug has been fixed in the lastest nightly build.
Comment on attachment 81630 [details] [diff] [review]
1.0 branch version: keep the offending window mostly invisible, but only on Windows

r=bryner, but with this not being in a windows-specific subdirectory I'd
suggest adding a very visible comment to the top of the jar.mn explaining what
this is for.
Attachment #81630 - Flags: review+
Comment on attachment 81630 [details] [diff] [review]
1.0 branch version: keep the offending window mostly invisible, but only on Windows

a=rjesup@wgate.com for branch checkin
Attachment #81630 - Flags: approval+
Branch and trunk patches are both in. That makes this bug mostly fixed, though
see comment 338 for late-breaking problems. Hah! I don't think I can quite close
this bug yet. I've also added a new bug 141361 to track the Mac trunk problem I
created. But it's much less visible now, at least. Adding the fixed1.0.0 keyword.
Status: REOPENED → ASSIGNED
Keywords: fixed1.0.0
*** Bug 141430 has been marked as a duplicate of this bug. ***
*** Bug 141470 has been marked as a duplicate of this bug. ***
*** Bug 141466 has been marked as a duplicate of this bug. ***
*** Bug 141594 has been marked as a duplicate of this bug. ***
*** Bug 142007 has been marked as a duplicate of this bug. ***
*** Bug 142013 has been marked as a duplicate of this bug. ***
Can we get this to the verified state soon?  It seems to have fixed my problem
with the compose window, but there were many different ways of hitting it. 
We're getting very close to zero for RC2 and it would be nice to have some warm
fuzzies on this one :-)
Well, can it be verified with comment 338 still valid?  This bug is not fixed in
the fullest sense yet.
Comment 321 is also still outstanding.
I think it's important to protect against drift -- this bug started out as
"Mozilla is so blatantly hard to minimize that people won't want to use
Mozilla", and we shouldn't let it wander into some other topic.

Comment 321 (un-minimize during page load) is not this bug -- this bug deals
with a static Mozilla, a Mozilla that is sitting around doing nothing.

I'm ambivalent about comment 338 -- it is a static un-minimize problem, but it
appears harder to trigger than the behavior that people have been complaining
about since the Jan 5 build.  Perhaps it's better to declare that the worst
behavior is fixed, close this bug, and open new bugs for remaining
minimize-restore problems.

(Mozilla appears to always have had minimize-restore problems, and I don't think
it was danm's mission to fix *everything*.)
jmorzins, I tend to agree that comment 321 is drifting from the original bug
reports, but any attempts to report the behaviour as a separate bug get closed
as a dup of this one. I was under the impression that this bug had been
generalized to cover the behaviour I see. I certainly have no problem with
calling this bug fixed, if we can open a new bug or re-open one of the 'dups'
for my problem...
There does come a time ... per discussion with danm, marking FIXED 
branch/trunk for the originally described scenario on this bug report 
(the (relatively-speaking) easy way to hit this unminimization).

I filed separate bugs for:
  http://bugzilla.mozilla.org/show_bug.cgi?id=142183 for comment 321
  http://bugzilla.mozilla.org/show_bug.cgi?id=142184 for comment 338

and http://bugzilla.mozilla.org/show_bug.cgi?id=141361 is also spun off to 
cover problems with showing the autocomplete dropdown on the Mac for trunk 
(but not branch) builds.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
*** Bug 142314 has been marked as a duplicate of this bug. ***
*** Bug 142333 has been marked as a duplicate of this bug. ***
This problem still occurs in WinME, Build 200241711
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
>------- Additional Comment #363 From jsako@megsinet.com 2002-05-05 10:25 -------
>
>This problem still occurs in WinME, Build 200241711

Can you please read the bug before you add a comment or reopen it ?
yes, this bug is near unreadable because of the many "stupid" spam comments.

please read : comment #306 (From danm@netscape.com 2002-04-25 17:38)

Your build is old !! 
Please don't reopen this bug again !!

If you get a problem with a new build (also in the future) , file a new bug but
don't reopen this bug !


-> fixed (sorry 400+ people who get a mail)
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
*** Bug 143015 has been marked as a duplicate of this bug. ***
*** Bug 143128 has been marked as a duplicate of this bug. ***
*** Bug 143343 has been marked as a duplicate of this bug. ***
*** Bug 143360 has been marked as a duplicate of this bug. ***
removing item for this bug from the release notes since the bug is marked
fixed. If this is in error, please make a note in the release notes bug for
the current milestone. As of today, this is bug 133795. In a ew weeks, it 
will be some other bug.
*** Bug 144137 has been marked as a duplicate of this bug. ***
*** Bug 146887 has been marked as a duplicate of this bug. ***
Build ID: 2002052306  Win2k

I just had this happen on RC3. I clicked minimize and the window only shrunk
about 50%. I'm using the classic theme. It's not happening often. So far I
haven't been able to reproduce it. I was viewing http://www.nytimes.com when it
happened.
This bug still occurs for me in RC3 (win2k) about one out of every five times I
try to minimize the browser window.  
I am running XP.
If I get the minimize problem, disabling quick launch resolves the problem (I
use the modern theme, by the way).
*** Bug 148660 has been marked as a duplicate of this bug. ***
Hi,

Disturbingly I received this again last night.  I'm using Mozilla 1.0 -
20020530.  It only happened with the last window that I wanted to close, but it
was definitely there.  Can't find what I did to replicate it though.  This is
the second time I've ever seen it and it definitely happened - I hit minimise
(Well Ctrl-M in W95) and it minimised, then bounced straight back up to the
equivalent of the restored position.  Ok - I know I don't have the latest build,
but since this was supposedly fixed ages before my build, I think it's still
worth reporting.
Re: Additional Comment #376 From Mark Mayo  2002-06-18 14:21
> Disturbingly I received this again last night.  I'm using Mozilla 1.0 -
> 20020530.  It only happened with the last window that I wanted to close, but it
> was definitely there.  Can't find what I did to replicate it though.

I (very very rarely) have this too, but as well with other applications. I
suppose *this* is more of a problem with the Windows shell (explorer.exe) than
with Mozilla.

> This is the second time I've ever seen it and it definitely happened - I hit
> minimise (Well Ctrl-M in W95) and it minimised, then bounced straight back up
> to the equivalent of the restored position.

After it restored back, did you try again? And if so, did it restore back again?
In that case, it most likely *is* a Mozilla problem. If not, then see above.
I also recieved this for the first time yesterday in Windows XP with the 1.1
Alpha build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a)
Gecko/20020611) It is a while since this bug has affected me, but i think its bac :(
Mozilla window can't be minimised at all sometimes ...
*** Bug 155721 has been marked as a duplicate of this bug. ***
Reopening.  As per bug 157897 (which I'm marking as a duplicate of this one) the
following URL cannot be minimized:

http://pub45.ezboard.com/bclonecduserforum

Confirming - reproducible every time.  I'm using 2002071608 trunk under Windows
XP.  The reporter of the duped bug was using Windows 98.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 157897 has been marked as a duplicate of this bug. ***
Marking fixed again.  Bug 157987 has been reopened, as it seems to be an issue
with the javascript on a specific page.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
This happened to me today (with current (1 day old) BRANCH_1_0 on Mandrake 8.2
Linux). I opened tons of pages in the tabs of a window and minimized the window.
Somehow it went restored by itself several seconds later ... I have javascript
on, but I've only allowed [x] "Open a link in a new window" and [x] "Change
images", everything other is turned [ ] off.
*** Bug 158101 has been marked as a duplicate of this bug. ***
I also keep getting this behavior from time to time on Windows 98 SE (on 1.1b
and nightly builds around that time), how come it's marked fixed?
verified fixed

If you see this with newer builds file a new bug because you see not this bug !
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: