640471 - After hitting "Stop script" or "Continue" the Unresponsive Script dialog doesn't trigger a second time, potentially leaving browser hung

Status: RESOLVED WORKSFORME

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

Description

[jag (Peter Annema)]

Attachment: Test: two infinite loop functions registered as load listeners

A simple test case is to register two "while(true){}" functions as listeners for the load event. For the first one we get the Unresponsive Script dialog. If you choose to stop it, the second function starts running, and you're not given another chance to interrupt it.

This appears to be a per-tab accounting issue. If I load a page which only registers one function, hit Stop, then re-load the page, it also hangs. If instead I do a second load in a new tab, I get the dialog. A re-load then, in either tab, again leads to a hung browser.

An interesting variant is having the second "while(true){}" function register with setTimeout() instead. Here you never get to see the Unresponsive Script dialog at all, just a hung browser.

Comment 1

[jag (Peter Annema)]

Attachment: Test: single infinite loop function registered as a load listener (reload to trigger bug)

Comment 2

[jag (Peter Annema)]

Attachment: Test: two infinite loop functions, one registered as a load listener, one with setTimeout

Comment 3

[jag (Peter Annema)]

Tested in 4.0b12 and 4.0rc on Mac. These scenarios don't cause a hang in 3.6.13.

Comment 4

[jag (Peter Annema)]

Regressed between 4.0b10 and 4.0b11. I'll start checking nightlies.

Comment 5

[jag (Peter Annema)]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b5cb26bbb10&tochange=1c2d53a2dcfb

I suspect it's http://hg.mozilla.org/mozilla-central/rev/835b313007b4

Comment 6

[jag (Peter Annema)]

Verified by backing it out locally. This regressed with the check-in for bug 621764.

For the second slow-script loop we currently seem to be hitting this with a depth of 1 where before that change we didn't:

  if (ctx->mModalStateDepth) {
    // We're waiting on a modal dialog, nothing more to do here.
    return JS_TRUE;
  }

Either "Stop script" or "Continue" will get us into this state, so the second test-case + "Continue" is enough to reproduce this.

Is it safe to just discard the return value of nsGlobalWindow::EnterModalState()? It seems to me that that way we never get the chance to call scx->LeaveModalState() to balance the count.

Maybe pass in a bool set to true from EnterModalStateWithWindow() so we can skip incrementing mModalStateDepth when we can't decrement it? There's probably a better solution though.

Nominating for blocking2.0 due to impact and simple "fix" (backout).

Comment 7

[Johnny Stenback (:jst)]

Dolske, looks like this is fallout from your tab modal dialog work.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Isn't that regression serious enough that we should fix it in a .x release? Re-asking for blocking2.0.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Nope, doesn't block 4.0.x

Comment 11

[Justin Dolske [:Dolske]]

I think bug 635888 just fixed this?

Comment 12

[Immatix]

Attachment: Stack trace for load listener, setTimeout hang

The test titled "Test: two infinite loop functions, one registered as a load listener, one with setTimeout" (https://bugzilla.mozilla.org/attachment.cgi?id=518292) is still reproducible in Firefox 8.0 Beta (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0) as well as nightly 10.0a1 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111028 Firefox/10.0a1).

Rather than displaying the script timeout dialog, the browser remains unresponsive until the process is terminated manually.

The two other tests seem to be fixed. The script timeout dialog will display twice even when Stop is selected the first time.

I've attached a hang stack trace from Nightly.

Comment 13

[Firefox Bug Husbandry Bot]

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.

Comment 14

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10x64 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-11), beta 86.0b9 and release 85.0.2. No crashes/hangs encountered during the tests. Tested both options for "stop it" or "wait" buttons and browser was perfectly functional afterwards or during the tests.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.