[Netscape® Communicator 4.8 : en-20020722] (release) (W2Ksp4) No bug. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.12pre) Gecko/20070322 SeaMonkey/1.0.8] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070322 SeaMonkey/1.1.1] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070326 SeaMonkey/1.5a] (nightly) (W2Ksp4) [Mozilla Thunderbird, version 2.0pre (20070326)] (nightly) (W2Ksp4) 1. Start Browser or MailNews (or TB). 2. Ctrl+M to compose a new message. 3. Type something in the body (for example). 4. Alt+F4 (or use the mouse...) to close the window. 5. Get the alert: "Save" the message. [No bug when using "Don't save" !] 5r. The previous window does not fully get the focus back: the icon in the taskbar is active, but the window itself remains grayed/background. Workaround: Press Alt+Tab once to reactivate the window. (Same with a brand new SM account.) [Mozilla Thunderbird, version 3 alpha 1 (20070326)] (nightly) (W2Ksp4) Can't test at the moment because of bug 372706, but presumably has the bug too.

[Mozilla Thunderbird, version 3 alpha 1 (20070326)] (nightly) (W2Ksp4) Confirmed on TBv3 too.

xref bug 209889

[Mozilla Thunderbird, version 3.0a1pre (2008020603)] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Bug still there.

OK, so there's a race condition: 1. The nsMsgCompose starts to open a progress dialog for the save operation. 2. The save operation completes, and recycles the compose window 3. The progress dialog opens, and tries to close again (in its onload handler) However, this does not take immediate effect; instead it runs from a callback, so that the dialog briefly flashes on the screen. This then appears to confuse someone's idea of where focus should be. I guess the workaround is to disable the progress dialog in this case.

I don't see this bug, neither on Linux nor OS X 10.4.11. So either I need better steps to reproduce or maybe it's Windows only?

Not a blocker.

Karsten in comment #7: > I don't see this bug, neither on Linux nor OS X 10.4.11. > So either I need better steps to reproduce or maybe it's Windows only? Karsten do you see it with mailnews.show_send_progress=true? (ref comment 5 and bug 209889 comment 9) if you don't see it then this bug is likely windows only. Is the lame hack good enough for TB3?

> > I don't see this bug, neither on Linux nor OS X 10.4.11. > > So either I need better steps to reproduce or maybe it's Windows only? > > Karsten do you see it with mailnews.show_send_progress=true? No, although that's true by default. I'd suggest letting a Windows person look at this, since I cannot review it in a meaningful manner.

Comment on attachment 328480 [details] [diff] [review] Lame hack Neil, needs different reviewer per mnyromyr. Removing pending review request

Comment on attachment 328480 [details] [diff] [review] Lame hack The progress dialog still flashes up after the compose window is recycled, although these days it doesn't seem to cause us to lose focus, but it's still a minor annoyance, so maybe we should still patch it?

Comment on attachment 328480 [details] [diff] [review] Lame hack I tried this on TB and it did get rid of the progress window flickering up...

Pushed changeset 6da4fcb1f555 to comm-central. I'm declaring this bug fixed.