Prevent execution of (some) scripts moving between documents

[domenic]

This causes scripts that move between documents between the preparation
and execution phases to not execute, aligning with most browsers. Closes
#2469.

This does not address #2137, which is about scripts moving between
documents between the parsing and preparation, or parsing and execution
phases.

• At least two implementers are interested (and none opposed): browsers mostly implement the most important part of this change, of not executing the script. Safari will execute classic scripts (but not module scripts). Chrome and the proposed spec in this PR never fire error events after such a move. Safari and Firefox fire error events in about half of the tested cases after such a move, but do not quite agree on which half of the cases. So, we specced the simplest behavior, of no error events at all.
• Tests are written and can be reviewed and commented upon at:
  • Scripts moved between documents web-platform-tests/wpt#19632, in particular the after-prepare test cases
• Implementation bugs are filed:
  • Chrome: not needed
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1632026
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=210841

(See WHATWG Working Mode: Changes for more details.)

---

/scripting.html ( diff )

[hiroshige-g]

Related to this, when we move scripts across documents, the following things (associated with Document) are not changed and thus, for example, set-of-scripts-that-will-execute-as-soon-as-possible of Document A can contain script elements that now belongs to another Document B, right?

https://html.spec.whatwg.org/#list-of-scripts-that-will-execute-when-the-document-has-finished-parsing
https://html.spec.whatwg.org/#list-of-scripts-that-will-execute-in-order-as-soon-as-possible
https://html.spec.whatwg.org/#set-of-scripts-that-will-execute-as-soon-as-possible
https://html.spec.whatwg.org/#pending-parsing-blocking-script

[hiroshige-g]

Also we might want to update the following non-normative notes:
https://html.spec.whatwg.org/#pending-parsing-blocking-script
https://html.spec.whatwg.org/#the-execution-of-scripts-that-are-moving-across-multiple-documents

[domenic]

In general let me know what you think. I am not 100% confident in my interpretation of when we should fire the error event, but I think the latest is pretty good. Happy to hear your thoughts.

Related to this, when we move scripts across documents, the following things (associated with Document) are not changed and thus, for example, set-of-scripts-that-will-execute-as-soon-as-possible of Document A can contain script elements that now belongs to another Document B, right?

I looked into these, and most of them are not a problem. The lists will indeed contain scripts from the other document, but that's OK, it just means when we go to execute them, we do nothing.

The pending parsing-blocking script is trickier, and I am not sure if maybe it is a problem. It seems like it might be OK to leave the spec as-is, and let it continue blocking until it is ready to execute, even though if it gets moved elsewhere, executing will be a no-op. What do you think?

Also we might want to update the following non-normative notes: https://html.spec.whatwg.org/#pending-parsing-blocking-script

If we go with the above (no change), then I think this note is still accurate.

https://html.spec.whatwg.org/#the-execution-of-scripts-that-are-moving-across-multiple-documents

This section seems to match the new spec text, but not match the old spec text, which is interesting. Did you have any change in mind?

[domenic]

Talked with @hiroshige-g in person to help me page all this back into my head. Things to do:

• When moving between documents, we have two reasonable choices:

  • The error/load event fires, depending on what happens on the network
  • Neither event fires, no matter what happens on the network

  Right now the PR is in a bad in-between state where if the network request succeeds, the load event fires, but if it fails, the error event does not fire.

  We prefer suppressing the events since the whole point here is to not run script, so it's a better conservative default.

• About the pending parser-blocking stuff, the PR's approach is good; it avoids having to do something at the time something is moved. But we do need to update the non-normative note, which currently says "at which time the script executes"; it should be "at which time the run a script algorithm runs (and immediately does nothing)" or similar.

• This may work better on top of Fix module script error handling, again #2991.

[domenic]

@hiroshige-g This should work better now; would love your review here and on web-platform-tests/wpt#5911 . I think our plan is still to not merge the spec change until we have shown this is web-compatible. However we can merge the test changes with a .tentative.html extension if that helps Blink's implementation.

[annevk]

Isn't this the same check as the one about the settings object above, except this one is restricted to "parser-inserted" elements? (And this one isn't really grounded in proper primitives.)

[domenic]

Nah, as the note below explains, it can occur in a slightly different scenario. The script's script is created during "prepare a script", but the Document of the parser that created the element is determined before "prepare a script" runs. I think there were tests for this difference in the linked WPT PR.

[annevk]

It seems Firefox doesn't restrict this to "parser-inserted" scripts as I found in #3486. I also think that if we need to keep this it would be nice to clean it up by actually having a place to store that document.

[domenic]

How can a script have a parser that creates it, but not be parser-inserted?

This is essentially a null-check, i.e.

if (script.parserThisWasCreatedBy !== null && script.parserThisWasCreatedBy.document !== script.nodeDocument) {
  return;
}

Without the first clause the second clause would "crash".

[annevk]

That's a good point. What I meant was that Firefox seems to store a creator document on all script elements and no longer execute the script element if its node document does not match its creator document.

[bzbarsky]

The actual logic in Firefox is that we store the creator parser and then don't execute if that parser's doc does not match the owner doc. See https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/dom/script/ScriptElement.cpp#134-144

If you have a non-parser-inserted testcase that's showing the behavior you mention, I can take a look to see what's actually going on with it.

[annevk]

@bzbarsky second test in #3486.

[bzbarsky]

Ah, we have an additional thing at https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#2182-2185

#3486 (comment) has more details.

[bzbarsky]

And in particular, we store a "creator document" on the queued-up thing, not the script itself.

[domenic]

BTW given results at web-platform-tests/wpt#5911 (comment) I am not sure why I wanted to wait on Chrome before merging this. Roughly matching 2/4 browsers with a better behavior seems pretty reasonable, especially given Chrome's expressed interest in aligning with this spec change.

[annevk]

Nobody has ever discussed changing the object's relevant realm (i.e. creation realm)

I'm pretty sure that's what Gecko does on adoption, @bzbarsky can correct me. If it didn't it'd still leak the old realm and the goal of changing the prototype and such on adoption is to not leak that.

[annevk]

In #3486 you state this would also fix that, but my results (note that I'm not testing the parser) have three browsers stacked against Firefox (and I haven't really tested external scripts yet).

[domenic]

So I think we could still merge this and then have additional fixes for #3486 on top. But maybe you want to get the full story fixed first?

[annevk]

I think I'd prefer it if we changed the "connected" check earlier to "browsing-context connected" and had a separate "scripting is disabled" check here with a qualifying example (and test). Since this example is addressed by improving the check earlier.

[domenic]

I'd prefer to make that change separately, since scripting being disabled is a separate concept from being browsing-context connected. There are other cases where scripting can be disabled but still be in a browsing context, e.g. if the user has disabled JavaScript.

[annevk]

I think I would prefer the full story since when we ask implementers to make changes it's better to have a full accounting of the changes we are asking them to make.

[domenic]

If that's the case I hope you can take over this PR and tests; I've done my best to converge on a behavior that has multi-implementer support, but I don't have time to do the full archeology here.

I'd still prefer landing this as a series of well-layered changes.

[domenic]

@annevk Chrome would like to ship this soon, at which point we would have 3/4 browsers matching this change. As I stated previously I would prefer to land this and then someone can work on #3486 on top of it. Do you still object to aligning with 3/4 browsers?

@cdumez any interest in aligning Safari on this?

[annevk]

I'm still a little unsure about making changes here that don't match anyone their model. But I guess none of it was well-defined to begin with...

[domenic]

Nevermind. This is redundant since we have tests for both parser/prepare-time and prepare-time/execution-time.

No, wait, it is not redundant, I think... The question is whether we fetch the script or not if there's a parser/prepare-time mismatch. I.e. we'd need to test whether the server gets hit. Anyway, this is all more about #2137...

[domenic]

This PR is now rebased on top of the editorial work in #5154 which should make it much easier to review, if you look only at the new commit. (Currently that commit is 29cd353.) It becomes a one-line insertion. And we could easily change it from "return" to "fire an error event then return".

[hiroshige-g]

Updated tests and results.

• When preparation-time document != node's document at the time of #execute-the-script-block: (see after-prepare-* tests)

  • Firefox: Fires <script>'s error events in all external script cases.
  • Chromium: No evaluation && no events (recently changed behavior).
  • Safari: Fires Window's error events for successful module scripts.
    In other cases, evaluating/firing events as normal.

• When parser document != preparation-time document at #prepare-a-script: (see before-prepare-* tests; Compat: Should the parser execute scripts created in another document #2137)

  • Current spec: No evaluation && no events.
  • Firefox: No evaluation && no events.
  • Chromium and Safari: evaluating/firing events as normal.

Note on Safari's behavior (probably not related to moving between Documents):

• Parse errors in module scripts seem to fire <script> error events instead of window error events.
• Transfer-encoding errors seem to be handled differently from ordinal fetch errors like 404.

[yureshwar]

Content scripts which are from extension are getting blocked if they are specified to run at document start. What can we do to execute the content scripts at document start from extension.

[domenic]

@hiroshige-g @annevk I've updated this rather-old pull request. It is now a one-line addition on top of #5154, so it should be easy to review.

I've also updated the OP to use the modern HTML Standard pull request template, so we can have a clear sense of how this matches browsers.

Please take another look!

[hiroshige-g]

LGTM.

According to the latest run of web-platform-tests/wpt#19632, the behavior diffs of current browsers are (after-prepare* cases):

• Firefox and Safari fires script or window error events
• Safari evaluates classic scripts

[domenic]

Edited the OP with Firefox and Safari bugs. Yay!