BuildID: 2001121803 If a mozilla alert dialog pops up when you are using another application, the Mozilla taskbar icon and window titlebar to blink. If OK is clicked, the Mozilla window keeps blinking with no way to stop it aside from closing it. Reproducible: Always Steps to Reproduce: 1.Open a Mozilla window that takes up say 1/2 of your screen 2.Open another small window in the other half of your screen. Telnet for example. 3.Type in a non-existant hostname in the URLbar. 4.Press Enter and then *immediately* click on the other application (Telnet) to get focus away from Mozilla 5.When the dialog comes up, click OK directly. (without first focusing Mozilla) Actual Results: The Mozilla window keeps blinking with no way to stop it. Expected Results: Mozilla stops blinking when it gets focus.

To XP Apps

This happens on my win 2000 with 0.9.7. i got today. It has always been happening on my windows machine. i never saw this happen on my solaris machine. this is very irritating when it happens. A new window (Ctrl N)from this window does not do this only the original window keeps doing this. All i can do is to do Ctrl + N and close the older(parent) window.

Happens at least with trunk build 2001121508 also (Windows 2000). Extremely irritating..

This also happens on Win98, WinMe

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

trudelle to triage

->law

Weird. I'm giving it to Dan, who seems to know something about this. It's some sort of modal window quirk.

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

I reported the same issue in a dupe bug 117965 already. Still I did some more testing and saw that I could reproduce the problem with mail, too. It happens, when you can't connect to a server and recieve a popup due to this. An easy way to reproduce this is to open a test account for a server that does not exist. Do the same defocusing like for the browser and you'll end up with a flashing messanger, too. (btw: as you'll have seen, this does not rely on the size of the window) my current build is: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7+) Gecko/20020102 BuildID: 2002010203 Actual Results: windows indicates that there's something new about this windows by flashing the title-bar and taskbar icon. that's ok (although it should blink only 3 times according to my settings). But when you focus the window, it won't stop flashing. (regardless if in tabbed or untabbed mode) Expected Results: after 3 times (or whatever the system setting for this is set to) of flashing the window should stop flashing. AT LEAST when focusing it ought to stop this, but it never does until you close the whole window. (closing some tabs won't work) I copied these lines from my other bug report, because I want to underline this feature of M$-windows. You can set (at least in WinXP, I believe in 2k&ME, too) the times a new window should be flashing before stoping this annoying behavior. I think, while we're at this, should be checking, if a possible fix for the problem fixes this issue, too.

It turns out this is caused by a leaking (alert) window object, the destruction of which the signal to stop flashing the parent is tied to. This bug is related to bug 99140, then. And yes, it's possible to specify a flash count right up front on Win98, 2k and XP, but the method we use is version agnostic and would be fine if not for the leak. I'm afraid I'm going to have to put this bug in the stabilization milestone for now. (Not to discourage any of our gentle readers from fixing the leak earlier.)

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

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

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

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

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

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

Trunk build 2002-02-04-03:WinMe I see this problem with today's build using the "-mail" flag. Even after logging into Mail the icon still flashes. Using yesterdays build with the same profile and it doesn't flash. Is this the same problem?

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

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

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

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

subject: + / flashing does anyone actually search for existing bugs anymore?!

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

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

Seeing this with 2002020703 on Win2K

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

FWIW, I am no longer seeing this with build 2002021203 (on Windows 2000). Haven't tried it under XP yet...

This still happens for me in 2002021303 on W2K.

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

this happened to me on w98 @work and w/ my w2k cvs builds @home, marking 98 as the lowest common denominator. Danm: for 1.0 if you can't get the flashing fixed, let's remove the flashing code.

Of course, fixing the leak and this bug would be the best solution, but one way or another we really have to fix this... If I knew how to read the purify log in bug 99140, I'd help.

Reading News and getting 'Advance to the next unread group' popup causes Mail&News flash forever. Reeeeally annoying. Bug wasn't there in 0.9.8 release, but todays 2002021708 build has it. Windows is WinXP Pro.

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

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

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

It's not a bug. It's a feature. It's the tamagotchy easter egg.

I was about to dig into the source (haven't done that much yet), but now I'm not able to make it keep blinking. Is it just me or has someone done something about this? Build 20020219 Win2K.

The steps to reproduce this bug still apply. 2002022003 Win2k

This bug stinks.

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

this is killing me. Dan, can you direct us at the object that is leaking? I'm willing to at least investigate...

I've created a patch (my first patch ever). In my testing this fixes the problem. Anybody willing to try and comment?

Explanation (according to my understanding): nsWindow::getAttention() calls gAttentionTimerMonitor->AddTimer() with the "parentmost" window handle, which isn't necessarily same as mWnd. Now when a user clicks a button in a dialog without first activating the window, it goes to the destructor I've modified and does KillTimer(). Previously it was using it's own mWnd for which KillTimer() did not find info. If a user focuses the window first, the timer is killed in nsGetAttentionTimerFunc() where it notices that it is the foreground window.

The patch fixes the problem for me on Win2k.

This patch is a workaround, not a fix. Spy++ tells me that the window that wanted the attention doesn't get destroyed, which is why the timer doesn't die either.

It's not a serious leak becuase closing the owner destroys the flashed window.

I'm confused - you say this isn't a fix, but Ere claims that the timer is set of the parent window anyway. Is this a legitimate fix that doesn't fix the leak, or simply not a legitimate fix? I mean to say, should we get this patch included in addition to whatever the leak fix is, when we find it? If so, let's land the above patch now..

Well, it fixes the symptom. But fixing the cause would also do that. I'm trying to track it down, but I think that it belongs to bug 99140. I think it's a political decision if this should be checked in.

I was suspicious because Windows automatically kills timers of deleted windows. If there's a good reason that the window isn't deleted, then ere's fix is fine. Hmm... I wonder which window handle GetAttention is originally called on. If that one is getting destroyed then ere's patch is right after all.

Actually, getAttention is called on the window which isn't destroyed (the parent in this case). So, I think my patch isn't really correct, because it will kill the timer also when a child window destroyed. Maybe we should discard this patch? I'll try to find where the window leaks so it can be fixed instead (I have an idea already).

Interesting.. it seems that the dialog window will leak references for example when the title bar is clicked. Still need to investigate further.

Comment just in case I get run over by a car before I'm completed :) Avoiding nsWindow::ConstrainZLevel seems to cure it. Not sure yet why, but will continue to investigate.

Sorry for the spam. Anyway, I found it. Now to clean it up and create a patch.

Explanation of the new patch that should correct the problem properly: In DispatchMouseEvent() event.widget was not always properly released. In ConstrainZLevel() the called window event may allocate event.mActualBelow even if it doesn't adjust the level (event.mAdjusted may be false).

To Neil's comment about the leak: I think that although the window was destroyed when its owner was closed, the object was not freed, because it had a reference count > 0.

As long as we're fixing these leaks, how about adding a NS_RELEASE(event.widget); to the WM_DROPFILES code at http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#3863 ?

Comment on attachment 71068 [details] [diff] [review] New patch to cure the cause Nice catch, Ere! Thanks for finding that. And I suppose we should include Bill's change as well, though that's in code commented out.

Thanks. Sure, should I create another patch to fix that WM_DROPFILES?

This patch fixes the leak Bill Law reported in comment #59.

sr=hyatt

For what it worths, I have been seeing this alot on the trunk build. I often think there is something to pay attention to but only to find it is a false alarm -- bad user experience. --> adding one more vote.

Can someone check these puppies in for Ere?

Who's the one causing user-visible actions from destructors anyway? (I'm not saying its bad to fix leaks, but it might also be good to fix the underlying problem that's making the leak visible. After all, things would start going badly again if the widget were owned by something that had to wait for a GC before it went away.)

Håkan: I'm the bug owner; that's my job. We're currently in 0.99 lockdown and this patch should not go in at all without approval from the 0.99 Authorities. However, I'm pushing this bug to them. Offline, where it belongs. David: Yes, the logic to stop flashing the window is probably flawed. On the other hand, before this bug or bug 99140 was filed, I made sure the flaw was left in to remind me to fix the leak :) Still, we should probably kill the flash timer on window activate, too.

danm, is this ready to go? There seems to be some confusion about whether it has the necessary reviews. There have been several requests sent by others to drivers and we're ready to consider it but can't tell if it's ready for us.

Well, yeah. Written by Ere, r=ed by me, sr=ed by hyatt (comment 63). And there's the third patch ("Patch to fix...") which is actually unrelated but also correct. It's in a block of code that's been commented out, so it won't affect anything.

Comment on attachment 71068 [details] [diff] [review] New patch to cure the cause a=asa (on behalf of drivers) for checkin to 0.9.9

Comment on attachment 71329 [details] [diff] [review] Patch to fix another leak (discussed in comment #59) a=asa (on behalf of drivers) for checkin to 0.9.9

Patches are in, flashing is no longer forever. Thanks, all.

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

I thought this would have fixed this problem: 1. Search > Find in this Page 2. Enter some junk (eg. "kshksjhdf") and press Enter 3. Text not Found message displays 4. Wait a second and the taskbar icon starts flashing. Is this a separate bug or should this fix have resolved this as well? 2002022703

Comment #74 From Dean Tessman is not reproducable for me 2002022703/WinXP

Comment 74 works as described for me on 2002022703 on W2K. However, once i close the search window, the taskbar stops the flash. In addition, the title of the window never flashes as it previously did before today in various situations.

Dean (comment 74): I cannot reproduce it either (w2k). Anyway, I think it is a separate issue. A window shouldn't flash if it is on the foreground.

You can turn this feature off, if you do the following: 1. Read the Contributors list and licenses completely (!) and thoroughly 2. Use Mozilla for 2 hours at a time every day 3. Use Mozilla shortly every 30 minutes, even at night 4. If you did this for one week, disable the Components Bar, create a new, valid Mailnews-Account (no dummy values), then click on the 3rd link on the start page in the message pane of Mailnews. You have to do all of that within 20 seconds. 5. Report here, if you had success. (If you are still able to write.)

This appears to me to still be a bug and people are still complaining that their "on-top", "auto-hide" taskbar stays on top when a Mozilla popup dialog is still open. It manifests for me on w2k with http error messages. I honestly don't know if it is now considered a feature, dependency or flaw, but I hope the behavior can either be eliminated or made optional. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530

That might be caused by the fact that the title bar will keep blinking until the window is activated. I think Mozilla should obey the os setting for how many times to blink, but it is a separate issue and not part of this bug.

Per #79, I too find this extremely annoying, since my personal preference with XP is to use a left side, wide columned taskbar, with auto-hide and on top settings. When an alert, etc., pops the taskbar, most of the alert, etc., is obscured! I fail to understand why this is treated as a focus situation in the first place - a Mozilla alert, etc., is NOT stealing focus from the Mozilla window which generated it. Certainly this does NOT happen with IE 6 (or any other program I run under XP) and Microsoft INVENTED the concept of focus. There is even a setting in the new XP TweakUI to ALLOW applications to steal focus. Mozilla 1.1a does not honor that setting. Cal Tinson

Actually, I think there might be another bug that will cause the dialog title bar to flash briefly even if it is the active window. Consider filing a bug on it.

> Certainly this does NOT happen with IE 6 (or any other program I run under XP) Sadly not all of us have XP... or are you willing to buy me a copy? :-)

I filed a new bug 152280 on this foreground window issue.

verified fixed