Open Bug 553936 Opened 10 years ago Updated 10 months ago
Invisible modal dialogs originating from the hidden window (e
.g . Unresponsive script, alert)
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 <email@example.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 <firstname.lastname@example.org> 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.