Open Bug 553936 Opened 10 years ago Updated 10 months ago

Invisible modal dialogs originating from the hidden window (e.g. Unresponsive script, alert)

Categories

(Core :: DOM: Core & HTML, defect, P5, minor)

x86
macOS
defect

Tracking

()

People

(Reporter: asqueella, Unassigned)

References

Details

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a4pre) Gecko/20100321 Minefield/3.7a4pre

On the Mac OS X it's possible for a modal dialog to be opened "on behalf of" the hidden window, which creates a dialog, which can not be seen (except for Expose) and can be only dismissed (if you're lucky) using keyboard.

I stumbled on this problem because an extension's (ubiquity) script running in the hidden window caused the "Unresponsive script" dialog.

Steps to reproduce (for a simple alert()): 
1. Evaluate the following in the Error Console:
Components.classes["@mozilla.org/appshell/appShellService;1"].getService(Components.interfaces.nsIAppShellService).hiddenDOMWindow.alert(1)

Actual results: alert window opened, but not visible.

Expected results: alert window is visible, even if it means parenting it to a wrong window.

For the unresponsive script dialog here are the relevant pieces of code:
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#1088
http://mxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/src/nsPromptService.cpp#770
http://mxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#363

I was going to patch it by adding a visibility check or special-casing the hidden window when I noticed there already is a visibility check here:
http://hg.mozilla.org/mozilla-central/annotate/41adb2307994/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#l660
just not for chrome per bug 465993 comment 25.

TBH, I didn't quite understand why should the chrome code be able to open modal children of invisible parents (point 1 in the referenced comment).

I just checked and this works (alert is visible) in:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090112 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/ca9d3c35fe47
and fails in 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090114 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/89811ac1b35a
...as expected.
I find a narrower regression range (testing on OS X 10.5.8).  (Be
aware that builds from around this date sometimes crash on startup
... but not always.)

2009-01-13-02-mozilla-central
  http://hg.mozilla.org/mozilla-central/rev/9dbded90af2a
2009-01-14-02-mozilla-central
  http://hg.mozilla.org/mozilla-central/rev/89811ac1b35a

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-01-12+22%3A45%3A00&enddate=2009-01-14+01%3A47%3A00

In this range I'd guess
http://hg.mozilla.org/mozilla-central/rev/d765319f547d triggered this
bug -- but probably didn't cause it.

author Dao Gottwald <dao@mozilla.com>
       Tue Jan 13 21:18:03 2009 +0100 (at Tue Jan 13 21:18:03 2009 +0100)
changeset 23627   d765319f547d
parent 23626      046f5da25280
child 23628       9daec2349061
pushlog:          d765319f547d
Bug 462222 - getZOrderDOMWindowEnumerator broken on both Linux and Mac.
Actually, http://hg.mozilla.org/mozilla-central/rev/8dae102faa15 seems
more likely:

author  Boris Zbarsky <bzbarsky@mit.edu>
        Tue Jan 13 14:32:30 2009 -0500 (at Tue Jan 13 14:32:30 2009 -0500)
changeset 23621 8dae102faa15
parent 23620    f0a8064d5a8e
child 23622     c91a6563377d
pushlog:        8dae102faa15
Bug 465993. When opening a dependent window with an invisible non-chrome parent, throw.
> TBH, I didn't quite understand why should the chrome code be able to open modal
> children of invisible parents 

Because not allowing that causes bug 465993.  We used to have no visibility check at all.  Then one got added.  That broke things for some chrome consumers, so we relaxed the check to not happen for chrome.  See bug 465993 comment 14.

It really sounds like we need to tell apart "invisible and will never be visible" windows (like the hidden window, say) and "not yet visible but about to become visible" windows (like the ones in bug 465993).

Then again, maybe we can just do the visibility check for all dependent windows, chrome-parented or not.  The chrome-parented windows in bug 465993's testcase are NOT dependent, but I wanted to leave the chrome behavior as it had been (no visibility check) to avoid breaking extensions.

John, does Firebug actually use a dependent window, or would causing bug 465993 for dependent windows again be ok?
(In reply to comment #3)

> John, does Firebug actually use a dependent window, or would causing bug 465993
> for dependent windows again be ok?

I can't answer directly since I don't know about dependent window. What I do now, and the only way to open chromebug now is 

var url = "chrome://chromebug/content/chromebug.xul";
       
win = opener.openDialog(url, "_blank", winFeatures, params);

Where we are in a XPCOM command line handler component, 
opener = appShellService.hiddenDOMWindow;,

(after checking to see if the window is already up via window-mediator).

Is that enough info?
> Is that enough info?

No.  What matters is the contents of winFeatures.
opener.dump("chromebug_command_line opening window with features: "+winFeatures+"\n");
           

gives: 

chromebug_command_line opening window with features: resizable,dialog=no,centerscreen,outerWidth=1680,outerHeight=1050
That wouldn't cause a dependent window.  Ere, jst, does doing this check for all dependent windows, even chrome-spawned ones, sound ok?
In bug 771977, I discovered that the unresponsive script dialog for script running in a sandbox associated with the hidden window failed to display its unresponsive script dialog. This may be a side effect of it being in the sandbox, or maybe we've stopped being able to open these dialogs?
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.