-
Notifications
You must be signed in to change notification settings - Fork 155
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
Effect of vertical-scroll policy #278
Comments
The feature, if enabled, should allow scrolling as usual -- it's enabled everywhere by default, and has to be disabled explicitly. When disabled, the feature should stop any frames from interfering with scrolling. So maybe this is just a matter of inverted expectations and unfortunate naming. However, the main frame should be scrollable, even if the policy applies to it; it should really just prevent script from interfering with the user scrolling. If it's going further than that, then that sounds like a bug in Chrome's implementation. @ehsan-karamad, can you look into that? In child frames, the feature should prevent all scrolling, I think, so that an infinitely long subframe that ends up filling the viewport doesn't trap the user, where they can't scroll past it. That shouldn't be the case for the top-level document, though. |
I confirming what Ian's points above; the frame is not targeted for scrolling at all to stop it from blocking vertically scrolling the page. Initially the policy was mainly about blocking the ability to The current behavior could undergo some further enhancements and I suggest posting all suggestions here on the github page. For instance, maybe we should not hide the scrollbars for a disabled frame (and make it scrollable if user changes the scrollbar position directly) as the current behavior is one restrictive but consistent solutio for an unscrollable frame. Finally to Ian's point about main frames, the policy AFAICT works as expected; to test I used the nice test page above, disabled |
So, does this policy need redefining as the ability for the document to be scrolled (either programmatically or by user action)? Also if when the policy is disallowed, the frame is not targeted for scrolling at all, does that mean it also prevents horizontal scrolling? To me, the fact that it doesn't apply to a top document seems like an inconsistency with other policies and not in line with the FP framework. Could that make this policy hard to understand? |
Yes the current behavior could be redefined (modulo adding a "vertical" before all notions of scrolling); and on the note, the current explainer could be polished a bit more. That said there might be other alternatives e.g., to split the policy into smaller bits; e.g., a script and input related policy which avoids
No horizontal scrolling should be intact. All notions of scroll within the context of
That's correct; it is inconsistent. But this policy does not quite make sense to be disabled for a main frame. Essentially, the main problem would be when a disabled frame opens a new window in which case the policy is disabled and the new window is unscrollable. An alternative could be to change the inheritance behavior for this policy (i.e., main frames do not inherit this policy from an opener). |
My understanding of
vertical-scroll
is that it prevents a document from interfering with the user's ability to scroll the document normally. So I made a demo, and it doesn't do what I expected in Chrome 74.https://featurepolicy.info/policies/vertical-scroll
Essentially, my demo runs this code:
So interestingly, this does the opposite of what I expect. If I set a FP of
vertical-scroll *
, I am able to scroll the frame (I'm using a touchpad on a laptop). If I setvertical-scroll 'none'
, then the frame becomes unscrollable. In fact, it doesn't even have any scrollbars. It seems like the policy is doing something different than expected, unless I have a flaw in my test strategy?The text was updated successfully, but these errors were encountered: