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

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Anthony Lieuallen]

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.

Comment 1

[Nickolay_Ponomarev]

Asking for tracking-e10s? for the crash, hoping this attracts the right people who can comment on the other issue too.

Comment 2

[Anthony Lieuallen]

Any progress?

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 4

[Adrian Florinescu [:aflorinescu]]

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

Comment 5

[janekptacijarabaci]

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

Comment 6

[janekptacijarabaci]

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.

Comment 7

[janekptacijarabaci]

Last bad: 50.0a1 (2016-07-25)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Built from https://hg.mozilla.org/mozilla-central/rev/7c669d5d63efceb12696cd65cfa72c296013dafb

First good: 50.0a1 (2016-07-26)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Built from https://hg.mozilla.org/mozilla-central/rev/ff1ef8ec0fd800bf6856c1572c3b1610c45e9b6a

Pushlog
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c669d5d63efceb12696cd65cfa72c296013dafb&tochange=ff1ef8ec0fd800bf6856c1572c3b1610c45e9b6a

The suspects are: https://bugzilla.mozilla.org/show_bug.cgi?id=1251841, https://bugzilla.mozilla.org/show_bug.cgi?id=1261842 and https://bugzilla.mozilla.org/show_bug.cgi?id=1278985.

Comment 8

[:shell escalante]

trying to clarify comment 7 - does that mean it worked on that latest build you tried on 7/26... so this can be closed?

Comment 9

[janekptacijarabaci]

Yes, I think it may be closed.

Anyone who has a different opinion please respond :-)