Closed Bug 116074 Opened 23 years ago Closed 23 years ago

Alert dialog causes window title and taskbar to keep blinking / flashing

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: wd, Assigned: danm.moz)

References

Details

Attachments

(2 files, 1 obsolete file)

New patch to cure the cause
1.25 KB, patch
danm.moz
: review+
asa
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Patch to fix another leak (discussed in comment #59)
601 bytes, patch
asa
: approval+
Details | Diff | Splinter Review 
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
Assignee: joki → pchen
Component: Event Handling → XP Apps
QA Contact: madhur → sairuh
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
Assignee: pchen → trudelle
QA Contact: sairuh → claudius
->law
Assignee: trudelle → law
Weird.  I'm giving it to Dan, who seems to know something about this.  It's some
sort of modal window quirk.
Assignee: law → danm
*** 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.)
Blocks: 99140
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
*** 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?!
Summary: Alert dialog causes window title and taskbar to keep blinking → Alert dialog causes window title and taskbar to keep blinking / flashing
*** 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.
OS: Windows 2000 → Windows 98
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.
Keywords: nsbeta1
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. ***
Keywords: mozilla0.9.9, mozilla1.0
this is killing me. Dan, can you direct us at the object that is leaking? I'm
willing to at least investigate...
Attached patch My first patch ever (obsolete) — — Splinter Review 

    
    

    
  
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.

    
    

    
  


  

        Attachment #70696 -
        Attachment is obsolete: true

    
    

    
  
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. 
Keywords: patch, 
          
            review

    
    

    
  
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.

        Attachment #71068 -
        Flags: review+

    
    

    
  
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

        Attachment #71068 -
        Flags: superreview+

        Attachment #71068 -
        Flags: approval+

    
    

    
  
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

        Attachment #71329 -
        Flags: approval+

    
    

    
  
Patches are in, flashing is no longer forever. Thanks, all.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0 → mozilla0.9.9

    
    

    
  
*** 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
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: