Compute "allowed to download" synchronously in navigation #6497
Conversation
75cd4b4 to
318a7b7
Compare
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
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 |
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 )