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

Compute "allowed to download" synchronously in navigation #6497

Merged
merged 1 commit into from
Mar 16, 2021

Conversation

domenic
Copy link
Member

@domenic domenic commented Mar 15, 2021

Helps with #1130 by removing a deep-in-the-algorithm-tree usage of source browsing context. Does not take care of #5597, but fixes the actual problems posed by the current architecture.

I'm not sure whether this is a normative change, as I'm not sure whether a browsing context's sandboxing flags could change during a navigation (especially given that a new navigation which might change the flags aborts the previous navigation).

/cc @jakearchibald since this was inspired by #6315 (comment)


/browsing-the-web.html ( diff )

Helps with #1130 by removing a deep-in-the-algorithm-tree usage of source browsing context. Does not take care of #5597, but fixes the actual problems posed by the current architecture.
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory they can change (and maybe in practice?):

when an iframe element's sandbox attribute is set or changed while it has a nested browsing context, the user agent must parse the sandboxing directive using the attribute's value as the input and the iframe element's iframe sandboxing flag set as the output.

but this is something we want to move away from and capture such state when we start a navigation. Primarily with help from policy container.

I think this is a good change overall though.

<li><p>Run <span>process a navigate response</span> with <var>navigationType</var>, the
<span>source browsing context</span>, and <var>navigationParams</var>.</p></li>
<li><p>Run <span>process a navigate response</span> with <var>navigationType</var>,
<var>allowedToDownload</var>, and <var>navigationParams</var>.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a navigationParams? When we eventually move <a download> into navigation that might be simplified by this. Are you considering that it's part of navigation in practice as part of app history? See #5548.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far I've kept navigationParams as only for the things that need to flow all the way into Document creation (so, they need to go from navigate -> process a navigate fetch -> process a navigate response -> page load processing model for X -> update the session history with a new page -> create and initialize a Document object).

As we pull more things off of source BC (e.g. user activation) the parameter lists for these "top-level" algorithms will grow a bit (e.g., things like this that need threading through the first three steps, navigate -> process a navigate fetch -> process a navigate response). At that point we might want to consider something more structured, such as renaming "navigation params" to "document creation params" and then using "navigation params" for these top-level things...

Good call on taking into account <a download> for app history. I'll open a tracking issue on the app history side to make sure that's tested and accounted for, and maybe I'll try to fix #5548 as part of this.

@domenic
Copy link
Member Author

domenic commented Mar 16, 2021

So I guess this could be manually testable, but not in an automated fashion, since we can't tell whether the browser bailed on the download or not. (I was thinking maybe there'd be a violation report, but I don't think so since sandbox="" doesn't generate them to my knowledge, only the CSP header.) I'll go ahead and merge without tests in that case... better to keep the cleanup-train at high speed.

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

Successfully merging this pull request may close these issues.

2 participants