1113012 - Slow script dialog is easily defeated

Status: NEW

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

Description

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

It's possible this bug is just WONTFIX, but I figure it's worth filing.

As far as I can tell, we make an effort to avoid running timeouts when the slow script dialog (or any modal dialog) is visible. However, some stuff still makes it through. Bug 1091705 comment 20 is one example where off thread parsing causes a script to be run while a modal dialog is visible.

Another example I thought of is XHR. Here's an example:

<script>
function reqListener () {
  while (1);
}

var oReq = new XMLHttpRequest();
oReq.onload = reqListener;
oReq.open("get", "testfile.txt", true);
oReq.send();

while (1);
</script>

We don't get a slow script warning at all with this script (assuming testfile.txt exists).

Comment 1

[Bobby Holley (:bholley)]

(In reply to Bill McCloskey (:billm) from comment #0)
> We don't get a slow script warning at all with this script (assuming
> testfile.txt exists).

Hm, why not? I'd think that webidl callbacks in general would be subject to the slow script dialog. What are we missing?

Comment 2

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

Sorry, I should have explained in more detail. Here's what happens:

1. The initial while(1) loop causes us to enter the slow script code.
2. That code disables the interrupt callback and enters a nested event loop while displaying the modal dialog box.
3. The XHR result comes in and we run the onload code. That enters another while(1) loop, from which we never recover (as the interrupt callback is disabled).

Perhaps, instead of disabling the interrupt callback while the slow script dialog is shown, we should instead replace it with a simpler interrupt callback that always kills the script? I'm not sure how complicated that would be, but it might not be too bad.

Comment 3

[Bobby Holley (:bholley)]

Yeah, seems like we should just set a stack-scoped bit on the XPCJSRuntime in XPCJSRuntime::InterruptCallback. If that bit is true, we're re-entering, and we should just kill the script with prejudice (but probably only if it's content). Then we can get rid of the code that disables the interrupt callback.