[css-overscroll-behavior] the inhibition of scroll chaining doesn't stop a users text selection from reaching out of its own scroll context
Reported by
h...@jonjohnjohnson.com,
Dec 4
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3629.0 Safari/537.36 Steps to reproduce the problem: 1. Go to https://bug-192344-attachments.webkit.org/attachment.cgi?id=356442 2. Hover mouse on bottom edge of screen white rectangles. 3. Scroll downwards, effectively pulling the white rectangles into view. 4. See the white rectangles snap up and sit just inside the "viewport". 5. Move mouse up onto the pink background text. 6. Scroll pink background text downwards and upwards a few times seeing how it can reach its scroll boundaries and never move the ancestor scroller, which would effect the movement of the white rectangles, by use of the `overscroll-behavior` property. 7. Finally, attempt to select the text inside the pink background, starting from the bottom and moving up to the top, passed the top edge of the viewport. 8. Notice that last action will chain the scrolling up from the inner scroll container, and causing the previously "snapped" outter snapport to scroll, pushing the white rectangles off screen. What is the expected behavior? A users text selection where a mouse moves passed/against a scroll boundary that is using `overscroll-behavior` of `none` or `contain` would not chain up to ancestor scroll containers. What went wrong? Perceived breaking of experience for the websites author/user. cc majidvp@chromium.org Did this work before? No Chrome version: 73.0.3629.0 Channel: canary OS Version: OS X 10.12.6 Flash Version: I describe this as perceived breaking of the site, because I think a ui like this is most cleanly achieved in this test case by use of the sticky position scheme with nested scroll containers instead of separate scroll containers that use hidden visibility or a `none` value of pointer-events for the scroll container, which is extremely buggy across vendors, when attempting to having hit areas for scroll interactions that depend on if something is scrolled (pulled out) into view or not.
,
Dec 7
Mac triage: into blink triage queues; the bug description is too technical for me to understand.
,
Dec 7
Video showing how teach scroller can be scrolled independently, though nested, by use of scroll-behavior property, but how text selection effectively breaks users expectations, "chaining" the scrolling at the inner scrollers boundary. http://cl.ly/00fc34b29453 cc swarnasree.mukkala@chromium.org
,
Dec 7
Also, majidvp@chromium.org, one can also use the space bar to scroll across these scroll boundaries, once focused in on any vertical scrolling text. Space & shift+space can easily show the behavior. What do you think here?
,
Dec 13
Assigning to majidvp to answer question above. Please set back to untraiged to revert back to queue.
,
Dec 13
So basically the suggestion is that `overscroll-behavior` should apply to selection related scrolling i.e., when user selection causes scrolling we should consider overscroll-behavior before we chain that scroll. This seems reasonable to me because it seems to me that the selection related scroll can be considered as a single scroll that originated from the element where selection was started. So it falls under what overscroll-behavior controls [1]. However, I am not an editing expert and I like to get an editing/text-selection expert advice here if this makes sense and in particular: 1) Will this run counter to expected behavior from user's perspective? 2) There is another property `user-select: contain` that seems to try to do something similar. This is not implemented in Chrome. Any idea if we ever plan to implement that and if their functionality will overlap? 3) Any pointer on where the selection related scrolling happens? AFAICT that scrolling does not go through blink::ScrollManager assigning to yosin@ who may be able to help answer the above. [1] https://drafts.csswg.org/css-overscroll-behavior/#valdef-overscroll-behavior-contain "The user agent must not perform scroll chaining to any ancestors along the scroll chain regardless of whether the scroll originated at this element or one of its descendants."
,
Dec 14
I filed this issue with the csswg 10 days ago -> https://github.com/w3c/csswg-drafts/issues/3394 Just to add to the discussion, I've noticed at least blinks implementation of overscroll-behavior will chain posfixed elements to the viewport and not other ancestor scroll containers. This is why text selection doesn't scroll the "inbox" in your initial demo of the property's release. https://ebidel.github.io/demos/chatbox.html
,
Jan 15
Route to Blink>Layout since auto scroll is implemented in LayoutBox::Autoscroll().
,
Jan 17
(5 days ago)
szager, any idea what's going on here? |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Dec 4