Closed Bug 1196270 Opened 8 years ago Closed 7 years ago

Session restore, about:blank, injecting a script which calls alert(), Firefox either hangs or crashes


(Core :: General, defect)

Not set



Tracking Status
e10s + ---


(Reporter: arantius, Unassigned)



(Keywords: crash)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150807094952

Steps to reproduce:

A user reported ( ) to Greasemonkey that if a script A) runs on about:blank and B) calls alert() and C) the about:blank page loads as part of a session restore, Firefox completely hangs before any window is shown.

I noticed the error logged to the console:

JavaScript error: resource://gre/components/nsPrompter.js, line 357: NS_ERROR_NOT_AVAILABLE: Cannot call openModalWindow on a hidden window

And confirmed this failure.  I attempted to detect this case with equivalent code (nsIDOMWindowUtils, isParentWindowMainWidgetVisible) to skip/delay running the script, but instead I get a _crash_!

The `var winUtils = ...` line runs OK, but the ` if (winUtils && !winUtils.isParentWindowMainWidgetVisible) {` line causes the crash (see linked crash report).

This code is running thusly:

A) The chrome.manifest registers an observer on profile-after-change,
B) which is handled by a (JS) component,
C) which loads a frame script,
D) which adds an event listener, for DOMContentLoaded.

The handler function for that event listener is where the code mentioned was inserted.

Ideally we wouldn't be observing DOMContentLoaded while the window is invisible.  If we can't get that, at least being able to detect that the window is invisible without crashing would be nice.
Asking for tracking-e10s? for the crash, hoping this attracts the right people who can comment on the other issue too.
tracking-e10s: --- → ?
Component: Untriaged → General
Ever confirmed: true
Keywords: crash
Product: Firefox → Core
Version: 40 Branch → Trunk
Flags: needinfo?(wmccloskey)
Any progress?
I'm afraid I won't have time to look into this deeply for a while. Here is a possible workaround though. At the top of the frame script you could send a sync message to the parent process. The handler for that message could take, which is a browser element, get the window utils from that, and then do the isParentWindowMainWidgetVisible check.
Flags: needinfo?(wmccloskey)
I couldn't reproduce this issue on:
Version 46.0a2 20160205004003 User Agent Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101
Version 46.0a2 20160204004009 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 
The browser didn't crash, I got some console errors, but I think they're not realated:
(firefox:14001): Gtk-WARNING **: GtkSocket 0x931f8c20 is mapped but visible=1 child_visible=1 parent MozContainer 0xa27fb3b0 mapped=0
Closed: 8 years ago
Resolution: --- → WORKSFORME
I'm sorry, but the bug persists (everything is identical) :-/

Firefox Nightly 48.0a1 (2016-04-08) x32
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Built from
Flags: needinfo?(jmathies)
Flags: needinfo?(adrian.florinescu)
Also tried on Linux:
Firefox Nightly 48.0a1 (2016-04-08) x64
Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Built from

Exactly the same problem.
Blocks: e10s-addons
Flags: needinfo?(jmathies)
Flags: needinfo?(adrian.florinescu)
Resolution: WORKSFORME → ---
trying to clarify comment 7 - does that mean it worked on that latest build you tried on 7/26... so this can be closed?
Flags: needinfo?(janekptacijarabaci)
Yes, I think it may be closed.

Anyone who has a different opinion please respond :-)
Flags: needinfo?(janekptacijarabaci) → needinfo?(arantius)
Closed: 8 years ago7 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(arantius)
You need to log in before you can comment on or make changes to this bug.