1328253 - [e10s] crash in nsGlobalWindow::AreDialogsEnabled when the authentication prompt is dismissed a few times

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jose María Acuña]

Attachment: ice_video_20170103-132329.webm

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

Enter this URL in the navigation bar Firefox Developer Edition 52.0a2 (2017-01-02) (32-bits):

data:text/html,<a href="http://feeds.feedburner.com/GoogleInbox" onclick="var x = open(this.href,'gtn-roster-iframe-id','toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=1,resizable=1,width=750,height=330'); x.moveTo((top.screen.width-750)/2, (top.screen.height-330)/2 ); x.document.body.innerHTML += '<iframe src=http://www.elandroidelibre.com/wp-content/uploads/2014/10/inbox-gmail.jpg onload=alert(prompt(\'Email/Password\')) style=height:100%;width:100%;border:0;position:fixed;top:0;left:0;overflow:hidden></iframe>'; return false;">Authentication</a>

See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1316798

1- Click on the 'Authentication' link
2- Re-click twelve more times
3- Close all floating windows
4- Crash ID 820a792e-3b1d-4c32-9cc1-b8c50b9ec8e0


Actual results:

Crash in browser tab


Expected results:

-

Comment 1

[Loic]

It's related to e10s and the crash is in FF50, even previous versions.
CR:
https://crash-stats.mozilla.com/report/index/9c80da01-5b8e-47a7-8c5b-4cc2c2170103

Another thing: I don't understand why with e10s enabled the dialog box about downloading a file (here an image) appears after clicking ~ 10 times. That's not the case in non-e10s mode.

Comment 2

[Jose María Acuña]

With the latest version today (2017-01-03) crash also occurs

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The crash volume isn't really high, but since we are moving more and more users to e10s, should get this investigate soon-ish. Stone is going to help that.

Comment 4

[Ming-Chou Shih [:stone]]

This is a kind of recursion bug. It also happens on non-e10s. Here is the js stack (e10s)

openRemotePrompt@file:///.../components/nsPrompter.js:496:15
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7
openRemotePrompt@file:///.../components/nsPrompter.js:499:9
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7
openRemotePrompt@file:///.../components/nsPrompter.js:499:9
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7
openRemotePrompt@file:///.../components/nsPrompter.js:499:9
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7
openRemotePrompt@file:///.../components/nsPrompter.js:499:9
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7
openRemotePrompt@file:///.../components/nsPrompter.js:499:9
openPrompt@file:///.../components/nsPrompter.js:540:17
nsIPrompt_prompt@file:///.../components/nsPrompter.js:728:9
prompt@file:///.../components/nsPrompter.js:581:20
onload@about:blank:1:7

Comment 5

[Ming-Chou Shih [:stone]]

We got overrecursed = true in nsGlobalWindow::SetNewDocument [1] and return error. The C++ call stack is
nsGlobalWindow::SetNewDocument
nsDocumentViewer::InitInternal
nsDocumentViewer::Init
nsDocShell::SetupNewViewer
nsDocShell::Embed
nsDocShell::CreateAboutBlankContentViewer
nsDocShell::EnsureContentViewer
nsDocShell::GetDocument
nsPIDOMWindow<mozIDOMWindowProxy>::MaybeCreateDoc
nsPIDOMWindow<mozIDOMWindowProxy>::GetDoc
nsPIDOMWindowOuter::EnsureInnerWindow
xpc::DOMXrayTraits::resolveOwnProperty
...

When failed, we reset nsDocShell::mContentViewer = nullptr in nsDocShell::SetupNewViewer. At next time js called Alert, it crashed in [2] because content viewer is null.

[1] http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/dom/base/nsGlobalWindow.cpp#2827
[2] http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/dom/base/nsGlobalWindow.cpp#3594

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Move to P3 according to the lower crash volume and not e10s specific issue.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.