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

Does "load an HTML document" miss respecting the navigation param's response's body? #10776

Closed
mbrodesser-Igalia opened this issue Nov 18, 2024 · 4 comments

Comments

@mbrodesser-Igalia
Copy link
Member

What is the issue with the HTML Standard?

1 invokes 2. The latter ignores navigation param's response's body.

This is relevant because 3 invokes 1 and sets the response's body in step 11 and populates the navigation params in step 11 with it.

Footnotes

  1. https://html.spec.whatwg.org/multipage/document-lifecycle.html#navigate-html 2

  2. https://html.spec.whatwg.org/multipage/document-lifecycle.html#initialise-the-document-object

  3. https://html.spec.whatwg.org/multipage/browsing-the-web.html#evaluate-a-javascript:-url

@domenic
Copy link
Member

domenic commented Nov 21, 2024

1 invokes 2. The latter ignores navigation param's response's body.

This is intentional. The body is consumed by step 3 of [1]. [2] is only about Document creation; there's no law saying that we must populate during the same algorithm as we create.

#8095 discusses making step 3 more rigorous, but I don't think there's any issue here.

I'll close this, but am happy to reopen it if I've misunderstood what you're getting at.

@domenic domenic closed this as completed Nov 21, 2024
@mbrodesser-Igalia
Copy link
Member Author

1 invokes 2. The latter ignores navigation param's response's body.

This is intentional. The body is consumed by step 3 of [1].

Is it? navigationParam's response is only used to process link headers. The navigationParam's response's body would have to be accessed somewhere and that seems to not happen.

[2] is only about Document creation; there's no law saying that we must populate during the same algorithm as we create.

#8095 discusses making step 3 more rigorous, but I don't think there's any issue here.

I'll close this, but am happy to reopen it if I've misunderstood what you're getting at.

@domenic
Copy link
Member

domenic commented Nov 22, 2024

It is accessed by this spec text (emphasis mine):

Each task that the networking task source places on the task queue while fetching runs must then fill the parser's input byte stream with the fetched bytes

As I said, #8095 discusses making this more rigorous, but I hope you can see how this accesses the response body, even though it doesn't use that exact variable name.

@domenic domenic closed this as completed Nov 22, 2024
@mbrodesser-Igalia
Copy link
Member Author

It is accessed by this spec text (emphasis mine):

Each task that the networking task source places on the task queue while fetching runs must then fill the parser's input byte stream with the fetched bytes

As I said, #8095 discusses making this more rigorous, but I hope you can see how this accesses the response body, even though it doesn't use that exact variable name.

TBH I don't see why this necessarily accesses the response body; one would presumably need more context to deduce that. It's fine to keep this ticket closed, given there's #8095.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants