Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compat: Should the parser execute scripts created in another document #2137

Open
jakearchibald opened this issue Dec 6, 2016 · 16 comments
Open

Comments

@jakearchibald
Copy link
Collaborator

@jakearchibald jakearchibald commented Dec 6, 2016

The spec says no:

[Scripts] parsed into different Documents than the one the parser was created for do not execute

But Edge, Chrome and Safari all allow it. Reduced test (see the console) - source.

I really like how this silly hack allows you to inject content in a streaming manner in a way that's very close to how a regular page-load behaves, including executing scripts, but some kind of streaming document fragment would be a better way to deliver that.

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Dec 6, 2016

The normative part is

  1. If the element is flagged as "parser-inserted", but the element's node document is not the Document of the parser that created the element, then abort these steps.

https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script

and

  1. If the element is flagged as "parser-inserted", but the element's node document is not the Document of the parser that created the element, then abort these steps.

https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Dec 6, 2016

Checking git log --grep "execut" I found:

This changed in:
7c52fca

Other commits that may be relevant:
90d9255
2ba7d3a
41c8f10

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Dec 6, 2016

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

I think https://bugzilla.mozilla.org/show_bug.cgi?id=592366 summarizes the issue well enough, no? It's possible to enable this behavior, but it leads to all sorts of complexity in the interaction of script elements and the parser, which is already quite complex. Absent an actual web compat need, I don't think we should be introducing this complexity into the spec and into implementations. Of course @jakearchibald just tried his hardest to introduce actual web compat need. :(

@jakearchibald

This comment has been minimized.

Copy link
Collaborator Author

@jakearchibald jakearchibald commented Dec 6, 2016

Meh, I'm proposing it as an alternative to innerHTML = fetchedContent, which doesn't execute script either.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

Well, except for the part where you said it executes scripts. ;)

Anyway, for this particular case the real question is whether the non-Gecko browsers are willing to align with the spec. If not, I would like to see a concrete spec proposal that describes what their actual behavior is, assuming they actually have the same behavior.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

And unrelatedly, we should in fact just have some sort of streaming-parse-into-an-existing-document API that doesn't involve hacks. Is there an existing issue filed on that?

@jakearchibald

This comment has been minimized.

Copy link
Collaborator Author

@jakearchibald jakearchibald commented Dec 6, 2016

I know it's something @domenic has had bouncing around his head. I'm hoping this iframe hack shows it could be easier than we initially thought.

I'd love to be able to do:

const div = document.createElement('div');
document.body.appendChild(div);
const response = await fetch(url);
await response.body.pipeTo(div.writable);

…or something.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Dec 6, 2016

I think the "concrete proposal" being discussed is to remove the line @zcorpan pointed out. That seems like the right thing to do unless we can get implementer commitment to remove this behavior in other engines. Hmm, @yuki3 maybe?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

Is just removing that line enough to deal with the issues Henri raised? As a simple example, has someone carefully stepped through the resulting logic and ensured that the parser being blocked and unblocked ends up being the same parser?

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

And, importantly, has someone audited every use of "node document" around the <script> processing model to make sure it (1) makes sense and (2) matches the non-Gecko implementations if this restriction is removed?

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Dec 6, 2016

If the script should be executed then this thread is reopened: https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Sep/0030.html

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Dec 6, 2016

Ah, I had forgotten about that one. It's been a while.

I strongly urge everyone in this discussion to read that entire thread, which describes the incompatibilities in behavior at the time, the crashes this behavior caused in WebKit at the time, and the lack of clarity around interactions with CSP and whatnot....

Then please come back with an actual concrete proposal and tests that show what browsers actually do in the various interesting edge cases.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator Author

@jakearchibald jakearchibald commented Dec 7, 2016

@bzbarsky I've created #2142 to discuss a less-hacky solution for streaming HTML into an element.

@hsivonen

This comment has been minimized.

Copy link
Member

@hsivonen hsivonen commented Dec 8, 2016

I think we should keep the spec as not executing scripts that have moved between docs during the parse. As the earlier-referenced W3C and Mozilla Bugzilla entries show, the spec text was arrived at as a result of implementor feedback resulting from first trying to do things the way that allowed the execution of moved scripts.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented May 12, 2017

Note that Edge allows less than Chrome (and I assume Safari) here; in Jake's reduced test case, it only logs "Inline script", and not "Inline script" + "External script" as Chrome does.

I'm going to write tests against this behavior and hopefully Chrome can conform with the current spec as part of also fixing #2673.

domenic added a commit to web-platform-tests/wpt that referenced this issue May 12, 2017
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
domenic added a commit to web-platform-tests/wpt that referenced this issue May 20, 2017
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
@domenic domenic added the interop label Aug 28, 2017
domenic added a commit to web-platform-tests/wpt that referenced this issue Feb 20, 2018
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
domenic added a commit to hiroshige-g/wpt that referenced this issue Nov 4, 2019
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
domenic added a commit to hiroshige-g/wpt that referenced this issue Dec 4, 2019
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
domenic added a commit that referenced this issue Dec 13, 2019
This adds a pointer to #2137, which remains somewhat contested, to the
relevant parts of the prepare and execute algorithms for scripts.
domenic added a commit that referenced this issue Dec 13, 2019
This adds a pointer to #2137, which remains somewhat contested, to the
relevant parts of the prepare and execute algorithms for scripts.
domenic added a commit that referenced this issue Dec 13, 2019
This adds a pointer to #2137, which remains somewhat contested, to the
relevant parts of the prepare and execute algorithms for scripts.
domenic added a commit that referenced this issue Dec 13, 2019
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.
domenic added a commit that referenced this issue Dec 13, 2019
This adds a pointer to #2137, which remains somewhat contested, to the
relevant parts of the prepare and execute algorithms for scripts.
hiroshige-g added a commit to hiroshige-g/wpt that referenced this issue Dec 18, 2019
This follows the changes in whatwg/html#2673, but also tests the issue at whatwg/html#2137 in favor of the current spec.
domenic added a commit that referenced this issue Jan 9, 2020
This adds a pointer to #2137, which remains somewhat contested, to the
relevant parts of the prepare and execute algorithms for scripts.
domenic added a commit that referenced this issue Jan 10, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.