47247 - Alert dialogs becomes unclickable

Status: VERIFIED DUPLICATE of bug 53589

(SeaMonkey :: General, defect, P3)

Description

[scott]

Every now and then, if an alert of some sort appears (such as "The operation
timed out when attempting to contact _______") while I'm on another window, the
alert box will be unclickable.  The box itself will be in the foreground, but
you cannot make it the active window (the main Mozilla browser box remains the
active window, yet it sits behind the alert box).  Clicking on the alert box
only seems to make it change color (to active) for a split second.  Clicking on
the [OK] button does nothing when this happens.  Only way to get unstuck is to
end task.

I believe timing is critical to reproduce this, but it happens to me a few times
a week because I switch amongst apps rapidly, and often start a page loading,
then switch away from Mozilla while I wait for it to load.  I haven't found a
100% way to reproduce this however.  It has been occurring for quite some time.

Comment 1

[scott]

Oops, forgot to mention: most recently happened to me on nightly build
2000080104, but has happened a lot in the past too.

Comment 2

[Rann Bar-On]

hmmm....I've seen this before on older builds, but only with the prefs dialog
box.  Occasionally, it refused to go away and mozilla didn't respond to any
mouse clicks.  When this happens, the only solution is to crash moz using
ctrl-alt-del.

Comment 3

[Sean Richardson]

I've seen what Scott is reporting here many times, but I can't confirm because
this report could be pointing at any of several of the bugs that bug 25684,
"[crash] modal windows/dialogs are not 100% modal", is dependent on. Any
modal dialog that does not have a well-defined parent can become unclickable,
including some that make the entire App unresponsive.

Scott, this report would be much more useful if you could completely describe
the Alert dialogs that become unclickable, enough to tell what code is 
responsible for that Alert, and thus, whether there is already a bug filed
for it.

It is relatively easy to reproduce these unclickable Alerts by using the browser 
buster, http://komodo.mozilla.org/buster/ (or choose "choffman's browser buster" 
from the Debug menu).
(1) Start Mozilla, create a New browser Window.
(2) Click on the _random site list_ link on the browser buster page.
(3) Actively test or surf with the other browser window.
(4) ALT-TAB around, using multiple apps and windows as usual.
After some time, one or more unclickable alerts will build up.

Scott, or anyone, if you want to add clear descriptions of Alerts that you
see go unclickable, it's worth keeping this bug open to collect them so
someone can check against the list of known bugs that cause this sort of
problem and see if any new bugs need to be filed.

Otherwise, while a real problem is reported here, without specific detail
it won't help get bugs fixed, and may as well be closed. Please don't be 
discouraged Scott: you did give good detail, and you couldn't have known that
this problem is caused by *many* bugs.

Comment 4

[scott]

Usually the alert that it happens with is the following:

"www.sitename.com could not be found.  Please check the name and try again."

This is probably because these are the most common alerts I get, and they are
the ones most likely to have me switching windows (while I wait for the page to
load, which is taking a while because it's going to time out).  In the process
of switching back to Mozilla, I catch it at the wrong moment and get locked out
as described earlier.

Maybe worth noting is that right-clicking on the button for Mozilla on the
taskbar (in the hopes of popping up the context menu and choosing Close) doesn't
work when this happens... no menu appears.  The only way to end-task is to
manually launch the task manager and do it from there.

On a side note: I often get the above Alert on sites that are actually working.
 I'll only get the alert on the first attempt.  Retry, and it works fine.  This
happens a LOT in mozilla, but in 4.x I only get the alert if it's really down.
The difference is very apparent.  Please email me separately if you can refer me
to the appropriate bug on this separate issue.

Comment 5

[Rann Bar-On]

this is definately something to do with modal dialogs not getting the focus
properly, confirming for now, but might be a dupe

Comment 6

[Rann Bar-On]

this is definately something to do with modal dialogs not getting the focus
properly, confirming for now, but might be a dupe

Comment 7

[Asa Dotzler [:asa]]

like all the other bugs that bug 25694 depends on this should be narrowed down
to a reproduceable tescase and assigned to the component that owns that dialog.  

Comment 8

[Asa Dotzler [:asa]]

duplicate of bug 25684 (unless there is a specific and reproduceable place where
this happens that is not already covered by one of the dependency bugs listed in
25684.)

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

Comment 9

[Doron Rosenberg (IBM)]

verified

Comment 10

[scott]

Please see bug 53589.  These are all the same.  Copied from my latest comments
to it:

This has happened to me twice today already.  One was another Password Manager
dialog... Mozilla opened up an additional window for a site that prompted for
username and password.  After entering them and clicking OK, the PM dialog
popped up offering to save these for me.  I think I might have clicked on the
previous window (one with my user/pass) right as this was happening.  Sure
enough, same lockup as before.

The other time today was during a new action: the Save As... dialog box when
saving a link as a file.  I can't remember the exact series of clicks that
locked it up, but this time it was the Save As box that was in front but
couldn't be made active.  Exact same symptoms otherwise.

Comment 11

[Asa Dotzler [:asa]]

reopening to dupe against bug 53589

Comment 12

[Asa Dotzler [:asa]]

dupe of bug 53589


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

Comment 13

[Blake Ross]

vrfy dup