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

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: arantius, Unassigned)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Reporter)

Description

3 years ago
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 ( https://github.com/greasemonkey/greasemonkey/issues/2229 ) 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_!  https://crash-stats.mozilla.com/report/index/a7b7fb75-df09-4150-a849-77d8d2150819

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.
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Component: Untriaged → General
Ever confirmed: true
Keywords: crash
Product: Firefox → Core
Version: 40 Branch → Trunk
Flags: needinfo?(wmccloskey)
(Reporter)

Comment 2

3 years ago
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 message.target, 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

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 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 https://hg.mozilla.org/mozilla-central/rev/d9b1a9829c8ee2862955043f28183efa07de3d2b
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 https://hg.mozilla.org/mozilla-central/rev/d9b1a9829c8ee2862955043f28183efa07de3d2b

Exactly the same problem.

Updated

3 years ago
Blocks: 905436
Status: RESOLVED → REOPENED
Flags: needinfo?(jmathies)
Flags: needinfo?(adrian.florinescu)
Resolution: WORKSFORME → ---

Comment 8

2 years ago
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)

Updated

2 years ago
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → WORKSFORME

Updated

2 years ago
Flags: needinfo?(arantius)
You need to log in before you can comment on or make changes to this bug.