Implement part of Document Policy for force-load-at-top for text fragment
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
People
(Reporter: mccr8, Assigned: mccr8)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
The scroll-to-text-fragment defines a "configuration point" for Document Policy, which is a boolean force-load-at-top. The idea is that a document can add this to their HTTP header and block scroll-to-text-fragment. This header can also, for some reason, block plain old element fragment scrolling.
I've implemented enough of this so that the force-load-at-top.html can pass, though I'm not entirely sure why the load from history scroll restoration part of the text passes, as I have not actually modified anything in session restore.
This patch does not implement the policy iframe attribute. This lets a outer page require a kind of minimum Document Policy from the inner page, via a special Sec-Required-Document-Policy in the request, and then the load gets blocked if the response from the server doesn't comply. While this feature makes sense for some Document Policy things that are requiring features to ensure performance, I feel like it doesn't make any sense for force-load-at-top.
Anyways, this chunk of code I've implemented doesn't exist as a spec outside of scroll-to-text-fragment so I'm not sure what to do with it, but I figured I'd file a bug and add a patch so Jan or whomever can take a look.
Assignee | ||
Comment 1•6 months ago
|
||
Assignee | ||
Comment 2•6 months ago
|
||
I should also dig around to other places where CSP is initialized (like where InitCSP is called) and see if I need to add in my "document policy support" there, too. But hey, tests pass.
Updated•6 months ago
|
Updated•5 months ago
|
Comment 3•1 month ago
|
||
This directive would be useful to address cross-window gesture jacking attacks whereby an attacker can trick a user into invoking a button in a cross-origin document.
See https://www.paulosyibelo.com/2024/02/cross-window-forgery-web-attack-vector.html
Updated•29 days ago
|
Assignee | ||
Comment 4•25 days ago
|
||
I've been looking at this. Peter helped a bit trying to figure out where the check should go. Although it looks like jjaschke already added a note that the check should get added to Document::ScrollToRef() (which is one of the places Peter mentioned to me). If I return from there if ForceLoadAtTop() is true, then all of the force-load-at-top tests pass. I'm not sure if that's a good sign or a bad sign. The spec changed from blocking scroll on load for element fragment for same origin navigation to not doing it and they didn't add any tests. I guess I should look into what the tests are actually doing. Peter also had some questions about how this blocking would interact with BFCache and I don't know if that is accounted for in these tests.
Updated•25 days ago
|
Assignee | ||
Comment 5•25 days ago
|
||
Description
•