To reproduce just click on the minimize button at the top right. After that the application should be sunken in the task bar of the OS, and the previous application that had the focus before that should receive the focus again. This regressed between 2005-06-14 and 2005-06-15. Perhaps this is a regression from the fix for bug 76831?

WFM. SeaMonkey 7/13-06 under XP. What do you mean by "blur" in the summary? What isn't the minimize doing properly?

This should explain the bug.

Ah! Okay, now that I understand, I'll change my WFM to say that I'm seeing the same thing. (It's odd that I didn't notice this until I looked for it specifically.) Can I suggest re-wording the summary so that it's clear what's meant? I suggest changing it to something like: "Minimizing browser window results in incorrect display state in taskbar, indicating that the browser still has focus." I'll leave the actual wording up to you, but I'd get rid of "blur" and add "taskbar" in some manner.

Also, fixing dependency order - if anything, this bug is being blocked by 76831's fix rather than the reverse.

Sure. As you already knew, I had a hard time, coming up with a good summary/explanation of the bug.

I find this whole bug quite strange. Shouldn't it be Windows itself that manages how it displays focused / unfocused applications? Or is it the responsibility of the application to tell Windows their correct state? Since Windows is animating the window to show us that it's being minimized, Windows must be aware that it IS being minimized. However, there must be some piece of the equation I'm missing. (Since I don't know anything about the technicalities, I don't find the fact that I'm missing something here all that surprising.) I'll just shut up now and leave it to somebody better equipped to think this through. <grin>

*** This bug has been marked as a duplicate of 29405 ***

This is definitely not a duplicate of bug 29405. Maybe you meant a different bug?

*** Bug 303523 has been marked as a duplicate of this bug. ***

*** Bug 303497 has been marked as a duplicate of this bug. ***

*** Bug 303426 has been marked as a duplicate of this bug. ***

The summary needs to be updated. This is more than a button that doesn't look right. Firefox/Thunderbird are not giving up focus when they are minimized.

(In reply to comment #6) > I find this whole bug quite strange. Shouldn't it be Windows itself that > manages how it displays focused / unfocused applications? With a normal application, using the Windows runtimes, this would be true. Since the Mozilla core applications draw their own windows using XUL and such, they are the culprit here. Seems like some invisible window (they really exist) is retaining focus. Is this fallout from splitting the window?

Note that minimizing the browser window by clicking on the taskbar button works just fine.

RE comment #14: When you click on the Firefox's entry in the taskbar, it does not look like it has focus which is correct but when another program is supposed to gain focus it still does not gain focus. And it could be that the invisible window has focus like comment #13 suggests.

My mistake, you are correct. Focus is still broken, it's just the traybar icon that looks okay.

The correct regression date is 5-June-2005 - 6 June-2005 (exactly: ID:2005060506-ID:2005070522). I verified it on 2 computers. Test: 1. Open Notepad. 2. Open Firefox. 3. Open a new window of Firefox. 4. Minimize the second window. 5. Minimize the first window. 6. Look at Notepad.

Sorry, there has been some pollution in one folder. The regression date is indeed 14-June 15-June like the reporter said.

> The correct regression date is 5-June-2005 - 6 June-2005 (exactly: > ID:2005060506-ID:2005070522). Is that a typo? The ID range you specified is a month, not a day.

(In reply to comment #19) > > The correct regression date is 5-June-2005 - 6 June-2005 (exactly: > > ID:2005060506-ID:2005070522). > > Is that a typo? The ID range you specified is a month, not a day. No, this is not a typo. It was a July folder, mistakenly named as June. In Dutch those names are very similar, so in this respect it is a typo. Only the BuildID spoke the truth. :) But I have verified that this regression occurred between 14 and 15 June, like the reporter told. So if this is important, someone with more (hourly) builds can easily find out when exactly the regression occurred.

As the original comment alludes to, the only change to nsWindow.cpp between June 14 and 16 is the fix for bug 76831. Does setting "config.trim_on_minimize" to "1" get rid of this problem? If so, then that fix is to blame.

Setting that preference doesn't change anything.

(In reply to comment #22) > Setting that preference doesn't change anything. Actually, it does - did you perhaps set config.trim_on_minimize to 1 instead of true?. You might be 'mislead' to set the value of |config.trim_on_minimize| by Brendan in https://bugzilla.mozilla.org/show_bug.cgi?id=76831#c442, where he states: "Comment 440 talks about "mozilla" paging too much (when config.trim_on_minimize defaults to 1, until today; or if you are foolish enough to set that pref to 1 after today)." He doesn't mean for the user to set it to 0 or 1, naturally. 0 is of course false and 1 is true. See /widget/src/windows/nsWindow.cpp, line 1626 -- if (NS_SUCCEEDED(prefBranch->GetBoolPref("config.trim_on_minimize", So it's a boolean: either |true| or |false|. And bingo, setting it to TRUE instead 'fixes' this particular focus bug. So to be clear, here are the steps: 1. about:config in the URL bar 2. Right-click, New -> Boolean 3. Enter "config.trim_on_minimize" (without quotes, natch) 4. For its value, use TRUE Brendan, the actual minimize bug is Ere's, right?

> did you perhaps set config.trim_on_minimize to 1 instead of true? That's what Dean said to do. <grin> > And bingo, setting it to TRUE instead 'fixes' this particular focus bug. Yes, that works for me also. (A browser restart is required.)

(In reply to comment #24) > > did you perhaps set config.trim_on_minimize to 1 instead of true? > > That's what Dean said to do. <grin> Apologies. The code reads the bool pref and then stores it as a static int.

> Apologies. No problem, it's all good now. :)

config.trim_on_minimize just changes WM_MINIMIZE to WM_SHOWMINIMIZED. This is the documented way (http://support.microsoft.com/default.aspx?scid=kb;en-us;293215) of keeping the working set from being minimized. This problem seems to be an unwanted side effect of this method. So, there's probably only one way to fix this: turn trim_on_minimize back on by default.

SW_SHOWMINIMIZED Activates the window and displays it as a minimized window. Makes sense that we're seeing this behavior.

Does this mean that when we activate another program then the mozilla app would get trimmed anyway because it gets deactivated? I'm guessing it doesn't get trimmed because then what would be the point of trying to avoid getting trimmed. If not then why not deactivate the window after minimizing it? Would deactivating the app using ShowWindow(hwnd, SW_HIDE) after minimizing also result in the app being trimmed? Or is there another way to deactivate the window?

I missed this before. I wonder if SW_SHOWMINNOACTIVE can be used instead of SW_SHOWMINIMIZED. SW_SHOWMINNOACTIVE Displays the window as a minimized window. This value is similar to SW_SHOWMINIMIZED, except the window is not activated.

The suggestion in comment #30 should work, assuming I am reading this correctly: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Windows/WindowReference/WindowFunctions/ShowWindow.asp I'll make a patch and test it and post my results.

I made a build with the suggestion in comment #30, but it had no effect on the problem.

Here's the patch I used, just in case I missed something.

Looking at /widget/src/windows/nsWindow.cpp with lxr shows that SW_SHOWMINIMIZED appears 5 times. Why did you only replace 2 of them? Sorry I've tried but haven't figured out how to build Firefox yet and then would need to learn how to make a patch.

I only replaced the ones present in the code touched by Bug 76831

This is still present in 1.5b1. WFM when clicking directly on the entry in the taskbar; but fails to give up focus when using minimize button in title bar, control box, right-click menu on taskbar entry, or alt-space-N.

(In reply to comment #36) > WFM when clicking directly on the entry in the > taskbar; See comment #15. It doesn't work quite right. Although the last sentence there is incorrect.

Closing in on 1.8b5/1.5b2 so not sure we are going to get this in.

vlad or pav, can one of you look into this?

James, any chance you can take a look at this when the native theme stuff is all finished up?

I can do, yeah.

it's too late in the release cycle to try to fix this.

SW_MINIMIZE does three things: 1) minimizes the window 2) activates the next top-level window in the Z order 3) trims the working set When config.trim_on_minimize is false we want to do 1 and 2 but not 3. SW_SHOWMINIMIZED minimizes a window and then activates that same window if it was not active. SW_SHOWMINNOACTIVE minimizes the window and doesn't change the active window at all. Neither one is going to work as a direct replacement. I think the solution here is to use ShowWindow to minimize the window and then perform step 2 ourselves. In nsWindow::SetSizeMode after the ShowWindow call, insert if (mode == SW_SHOWMINIMIZED) { HWND hwndBelow = GetNextWindow(mWnd, GW_HWNDNEXT); if (hwndBelow) SetForegroundWindow(hwndBelow); } Then in nsWindow::ProcessMessage, in the WM_SYSCOMMAND handler, change the ShowWindow call to SetSizeMode(nsSizeMode_Minimized). I don't want to download and build the entire tree, but this approach worked for me in a small test application. Can anyone test this to see if it solves the problem?

Like this James? It seems to work sometimes, but not always Also, I'm getting an assertion often the first time when minimising the window: ###!!! ASSERTION: invalid active window: 'Error', file c:/mozilla/mozilla/embedd ing/components/windowwatcher/src/nsWindowWatcher.cpp, line 924 Not sure if it is related, though.

(In reply to comment #44) > Like this James? Did you mean to attach a patch, Martijn?

Oops! Yes, I meant to attach this patch, based on comment 43.

Yes, that patch is what I suggested. Too bad it doesn't work. Perhaps it is because SetSizeMode updates mSizeMode in addition to actually doing the ShowWindow call. In that case, changing the WM_SYSCOMMAND handler back to not calling SetSizeMode and just doing the SetForegroundWindow call directly might help. Specifically: case WM_SYSCOMMAND: // prevent Windows from trimming the working set. bug 76831 if (!gTrimOnMinimize && wParam == SC_MINIMIZE) { ::ShowWindow(mWnd, SW_SHOWMINIMIZED); + { + HWND hwndBelow = GetNextWindow(mWnd, GW_HWNDNEXT); + if (hwndBelow) + SetForegroundWindow(hwndBelow); + } } If that's not the problem it might be the code in the WM_WINDOWPOSCHANGED handler that responds to a minimization. I don't understand exactly what's going on there though. I don't have any insight on the assertion failure either, unfortunately.

That alos doesn't seem to help.

*** Bug 317791 has been marked as a duplicate of this bug. ***

I too was wondering how Firefox could be over-riding standard Windows operation, and I found out here. This problem was very annoying, and that fix made it act normal again. Thanks a lot, Stephen Donner.

*** Bug 323984 has been marked as a duplicate of this bug. ***

there is a related bug, in Windows. When Firefox is started with the API call 'ShellExecute' it ignores the 'nShowCmd' parameter. Or rather, it appears that in Firefox's Windows startup code the API is used (probably 'ShowWindow)' to maximize the application. In my experience the commercial an app is the more likely they are to do this. For instance, iTunes insists on starting maximized. IMO, this is bad progreaming practice. No question, virtually every time a user starts Firefox they want to see what they started. So this kind of failsafe programming stuff is understandable by a nervous programmer. Nevertheless the Windows Shell itself applies the SW_SHOWNORMAL or SW_SHOWDEFAULT when an icon is double-clicked (or the equivalent). This kind of thing is not necessary. -- I wrote a small app to start apps when Windows starts up (if it a certain time). But I want it to start some of them minimized, but right now I can't do this with Firefox and I am frustrated. I used ShellExecute with the 'nShowCmd' param as SW_SHOWMINIMIZED. This works fine for other programs but Firefox arrogantly insists on being seen when it starts.

*** Bug 328584 has been marked as a duplicate of this bug. ***

*** Bug 329329 has been marked as a duplicate of this bug. ***

> case WM_SYSCOMMAND: > // prevent Windows from trimming the working set. bug 76831 > if (!gTrimOnMinimize && wParam == SC_MINIMIZE) { > ::ShowWindow(mWnd, SW_SHOWMINIMIZED); > + { > + HWND hwndBelow = GetNextWindow(mWnd, GW_HWNDNEXT); > + if (hwndBelow) > + SetForegroundWindow(hwndBelow); > + } > } I haven't tested this, but this doesn't sound like it would move Firefox to the bottom of the Z-order (which minimising it should do).

We can clearly see with this tool <http://java.sun.com/docs/books/tutorialJWS/uiswing/events/example-1dot4/WindowEventDemo.jnlp> (http://java.sun.com/docs/books/tutorial/uiswing/events/windowlistener.html) that nothing is sent to Windows. It's clear for me that the patch for bug 76831 should be backed out. It's just a default preference change and it's the normal behavior for the Windows apps, so there's no reason to create a more annoying bug which perhaps depends on a Windows bug. In my opinion, this bug is worse than the bug 76831 for the look and feel.

Internet Explorer doesn't trim on minimize and doesn't have this bug. So it's clear that there's a way to do it.

One other symptom (which I assume is caused by this bug): Any program that currently has the window focus can be minimized by clicking on the application in the taskbar. This doesn't work for firefox.

*** Bug 346402 has been marked as a duplicate of this bug. ***

In reply to #58: It does work, but leads to very strange and unexpected behaviour. You can minimise the window by clicking the taskbar icon. Sometimes, it simply remains focused, sometimes it looks "unpressed" but is pressed again when moving the mouse cursor out of and back in the icon area, with no clicking anywhere. But in any case, the window is not moved to the end of the z-order and no other window gets the focus. This bug really is annoying, I use Alt+Tab a lot and find myself switching to the wrong window all the time, when I minimised Firefox or Thunderbird. I have never seen any application that does stuff like this. Does the application design really have to be that complicated that such errors occur and can't be fixed over a year? Why don't other applications have that problem?

This patch makes the correct window active when minimizing Firefox when using the hack to prevent working set minimization. It also pushes the application to the bottom of the window stack. I had to block SetSizeMode calls that pass the current sizeMode in as this was causing all sorts of problems when you minimized a window using window.minimize(). (Calculating the right window to focus is not going to work very well once you've already been here once and pushed yourself to the bottom!) API compatibility: all implemented in Windows 95 and Windows NT 3.1.

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize You could compare directly to mSizeMode avoiding the call to GetSizeMode (nsWindow::Show does that too), but this would be ok.

(In reply to comment #61) > Created an attachment (id=231241) [edit] > Focus next suitable window on minimize > > This patch makes the correct window active when minimizing Firefox when using > the hack to prevent working set minimization. You patched SetSizeMode, but not the WM_SYSCOMMAND handler (see the patch from comment 46). Is unnecessary for some reason?

Yeah, the SetSizeMode code is called both when the application asks to minimize, and when it is told by the OS that it has been minimized. If the user minimizes the window through any OS-powered means, the WM_SYSCOMMAND code handles the trim stuff, and then the OS's notification of being minimized triggers SetSizeMode to active the right window. If the application directly calls SetSizeMode, this handles the trim stuff and the activation of a new window. After this, the OS notifies us of the minimize and this triggers SetSizeMode again - which I added code to ignore, as we'd already done everything necessary the first time.

Not wanting to question your solution or anything, but please may I ask why it is necessary to manually determine the next window and activate it? Shouldn't the OS be responsible for that when a window minimizes or is minimized?

The application is specifically asking that the OS does *not* do that when it is minimized, hence it needs to do it manually. This is because the OS combines a number of operations behind the scenes with SW_MINIMIZED: - minimizing the window - choosing and activating another window - marking the non-shareable portion of the working set as unused While the ideal solution would obviously be fixing the memory problems that plague the restoring the working set; the option currently employed is to try and stop the OS from marking the working set as unused in the first place. The way this is done, and I don't know of a better way, is to use SW_SHOWMINIMIZED, which causes the window to be minimized but *also still active*. As the window is specifically being asked to keep the focus, the OS does not try to focus anything else, so we have to go and do that bit.

And why doesn't any other application seem to have problems with Windows' memory management? Or another way: I beliebe the Mozilla Foundation would have sufficient capabilities to known on Microsoft's door and ask them to fix their memory manager commonly known as broken in several ways. That would probably help a lot more people then just Firefox users which are increasingly running away to Opera btw.

It's Firefox that has the memory management problem. None of this concerns this bug, though.

*** Bug 348189 has been marked as a duplicate of this bug. ***

James, you want me to check this in the trunk, or are you doing it yourself? Thanks for the patch!

I'm landing right now (well, when the trunk stops burning). I was away from Tue until now, and couldn't watch the tree.

OK, I am not landing this now and I don't want anyone else to - there are no Windows tinderboxes on SeaMonkey, and I refuse to check-in in this situation. Hopefully this issue will be resolve swiftly (hahaha).

(In reply to comment #72) > OK, I am not landing this now and I don't want anyone else to - there are no > Windows tinderboxes on SeaMonkey, and I refuse to check-in in this situation. > Hopefully this issue will be resolve swiftly (hahaha). Creature is now back up ;)

Checked in --> FIXED.

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060811 SeaMonkey/1.1a] (nightly) (W98SE) SM v1.1a has this bug too.

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize >+ ::SetWindowPos(mWnd, HWND_BOTTOM, 0, 0, 0, 0, >+ SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE); It's a good thing we don't support minimizable topmost windows ;-)

Neil, if you make another snide remark on any bug I'm working on you can forget me doing any more work. I'm sick to death of it.

Won't block the release for this, but we'll likely take the patch.

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize a=mconnor on behalf of drivers

Using TB 3a1-0808, I can verify this patch fixes the problem, but I'll put marking it verified until it's on the branch. (I *hope* it ends up on the branch.) James, thanks for this patch; the behavior that you've fixed has been bothering me for months, and I never saw this bug until noticing it on Bonsai Watch, so I didn't know about the workaround. There is at least one additional normal minimization behavior that is not covered by this patch: the minimize sound is not played. I can live with that, but I'm going to repurpose bug 295355 (which I opened for this problem) to be about the sound issue; maybe somebody can address that issue in a future patch.

Landed on MOZILLA_1_8_BRANCH.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060815 SeaMonkey/1.1a] (nightly) (W98SE) Fixed: Minimizing using SeaMonkey means (= keyboard/mouse) :-) "Improved", but not fixed: Minimizing by clicking on the active entry in the Windows taskbar. Now, the Seamonkey icon correctly "sink" :-) But, if there is another (SeaMonkey or not) opened window, it kind of "getAttention()" instead of activating.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4] (release) (W98SE) Same bug on v1.8.0 branch. (For consideration when v1.8.1 branch is fully fixed.)

Serge, that'll be Windows 98 or 9x specific I guess, as things are fine on XP and 2003. If you want to file a followup bug for it you can, but I don't think I'll be able to help as I've not got anything predating Windows 2000.

I filed bug 348723. Then, considering V.Fixed on MOZILLA_1_8_BRANCH here.

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize 'approval1.8.0.7=?': Per comment 83 and comment 85.

Does the patch author think this should be part of a security release? (Generally we are, or at least should be, much more skeptical of approval requests not by the patch author, since the patch author has considerably more understanding of how risky the patch is.)

With regard to risk, I regard this patch as a low risk. It improves the situation on most Windows systems, and does not cause a problem on older systems. If you are accepting non-security patch for 1.8.0.7, I would like this patch to be included. (The fact I thought you weren't accepting non-security things is the only reason I didn't request approval myself.)

Comment on attachment 231241 [details] [diff] [review] Focus next suitable window on minimize out of scope for a security/stability release.

(In reply to comment #89) > (From update of attachment 231241 [details] [diff] [review] [edit]) > out of scope for a security/stability release. (I know, but too bad, in this specific(!) case. The only reason for which I did not complain earlier/louder was that I (lazily) thought that it was Windows fault :-/ This really is a major failure at the "operating system/desktop integration", to whoever uses the taskbar rather than the window buttons.)

I can't help but strongly disagree with this "out of scope" assessment. Not wanting to start any fight here or anything, but I just think that it pretty easily looks like a stability issue to many normal users. Then again, maybe I'm saying that because I also think normal users deserve more regular bugfix releases, which currently appear to be half a year apart. How significant does a bug need to get that a normal user can expect it to be fixed without having to wait for the next major release with its own major new features and new bugs? I'm sorry, I didn't want to make this sound like a rant.

If this were 1.5.0.2 or even 1.5.0.5 we'd probably have taken it, but we must get 1.5.0.7 out in front of FF2 and can't afford the distraction of "nice to have" bugs. Sure, any given bug sounds eminently reasonable and small, but there are tons of such bugs and we have to draw the line. If 1.5.0.7 doesn't make it out before the FF2 RC's start (in a couple weeks!) then it gets pushed out after FF2 because of build/QA resource constraints. That's way too long to sit on the security fixes (probably end of October early November by then). Sorry to be the Grinch here.

No need to be sorry, and thanks for the explanation.

(In reply to comment #77) >Neil, if you make another snide remark on any bug I'm working on you can forget >me doing any more work. I'm sick to death of it. My remark was not meant to be snide, and I'm sick of your attitude (but not quite as sick as Microsoft for making it so hard to minimise a window).

(In reply to comment #94) >sick as Microsoft for making it so hard to minimise a window Wait... (not meaning to offend anyone here) Wasn't it Mozilla/Firefox' fault that all this doesn't work correctly? Somebody mentioned a memory management bug here. I have no problems correctly minimising a window of any application, including my own, without any code at all. Just leave it up to Windows and it'll work like it should. Don't blame Microsoft for your* fault. Look at Adobe Acrobat/Reader 7 and its poor multi-window implementation. Using Alt+Tab is a pain. They'd better left it the traditional MDI way. Microsoft did this very nice in their Office 2003 now. *) whoever actually did it.

My understanding of this is: * Firefox/Thunderbird (more precisely: the core libraries incl. the GUI toolkit) use a lot of memory, way more than theoretically necessary * If the "working set" gets "trimmed", this data sometimes gets swapped out * Windows "trims" the "working set" if you minimise a window * Therefore, bringing the window back up from minimised state may swap in a lot of data, causing unresponsiveness * In order to maintain some level of responsiveness in Firefox/Thunderbird, Mozilla have decided to tell Windows not to do minimising normally (unless config.trim_on_minimize is set), instead of fixing the root cause * Thus, all the minimising stuff is done manually, instead of focusing attention on the root cause * Mozilla gets it wrong * People complain * More effort is spent on producing the most perfect copy of OS behaviour instead of just using normal OS mechanisms and focusing attention on the root cause * People are stuck with this annoying bug for another half-year, until a new release with the bugfix will finally come out, but the root cause still in place

While I agree with the sentiment that this is a workaround on a workaround, I would like to point out that the actual base problem is not that well understood. It is obvious that higher memory usage would be a factor but, at the same time, many apps that use significantly more memory page back in much faster than Firefox. They also tend to start responding well before all the memory is paged back, contrary to Firefox. From this, it seems more likely that it is how the memory is used (size of allocations, number of stacks, spread of 'executable' code over memory regions, etc.), and that certainly is not easy to investigate nor simple to change.

The "config.trim_on_minimize" option! This is what makes me happy today! I've set it to true in both Firefox and Thunderbird and now it will minimise my windows perfectly! :) I have 2 GB RAM with no swapping file at all because it has always slowed down my system, thus any memory swapping behaviour is not an issue for me. Thanks a lot for that tip, Timwi!

Comment #97 - isn't that problem with mmap()ed resources? And that hack with minimization was implemented precisely to avoid Windows knowing that Mozilla is minimized so it would not discard file backed memory. I have seen that description on bugzilla/etc somewhere before - in the times when the hack was implemented. In other words, it's not problem of Windows per se - it's problem of Mozilla/Firefox to rely so heavily on mmap()/CreateFileMapping(). I have no sufficient knowledge of Mozilla programming, but somebody could try to test that: replace mmap()ing of .jar's with plain malloc() + open() + read() + close(). Unmapping: instead of munmap() do free(). I have personally been burned by unpredictability of mmap() much and prefer straightforward file io.

I've not seen problems since this patch has landed, and it has indeed fixed the problems that were aggravating me for quite some time on Windows XP, with both SeaMonkey and Firefox. Verified FIXED on trunk with build 2006-09-10-08 of SeaMonkey on XP. Note also that Serge has split out his Win 98-specific problem into bug 348723.

Possible regression? Bug 358812 - Minimizing Firefox window using task bar button restores focus differently than minimize ( _ ) button on Firefox window