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

Effect of vertical-scroll policy #278

Open
triblondon opened this issue Feb 15, 2019 · 4 comments
Open

Effect of vertical-scroll policy #278

triblondon opened this issue Feb 15, 2019 · 4 comments
Labels
feature question Questions and issues around specific policy-controlled features

Comments

@triblondon
Copy link

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:

document.addEventListener('scroll', e => e.preventDefault());

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 set vertical-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?

@clelland
Copy link
Collaborator

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.

@ehsan-karamad
Copy link
Contributor

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 preventDefault an event but mainly due to issues raised in this bug we decided to make the disabled frame (e.g., a frame which has vertical-scroll disabled) not targeted for scrolling altogether. To this end, the scrollbars are removed as well.

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 vertical-scroll and window.open' to the same page. In the newly window main frame _is_ scrollable but the child frame is _not_ regardless of the allow` attribute.

@triblondon
Copy link
Author

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?

@ehsan-karamad
Copy link
Contributor

So, does this policy need redefining as the ability for the document to be scrolled (either programmatically or by user action)?

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 preventDefault and any script from blocking vertical scrolling and some other policy X which would block a page from scrolling along a certain direction indefinitely (making the frame not scrollable along y-axis is one such solution). I think @RByers once suggested something about maybe dividing the current policy into smaller ones as the current policy is very restrictive.

Also if when the policy is disallowed, the frame is not targeted for scrolling at all, does that mean it also prevents horizontal scrolling?

No horizontal scrolling should be intact. All notions of scroll within the context of vertical-scroll policy deal with y-axis vertical 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?

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).

@clelland clelland added the feature question Questions and issues around specific policy-controlled features label Mar 25, 2019
@clelland clelland reopened this Jun 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature question Questions and issues around specific policy-controlled features
Projects
None yet
Development

No branches or pull requests

3 participants