[css-visibility][css-pointer-events] Removing pointer interactions on a 'scroll container' itself (or ancestor) and re-enabling them on descendants, doesn't allow for scrolling itself to scroll from those descendants. Always iOS, sometimes desktop.

[jonjohnjohnson]

To start out, I'm sure this is intentional because of the way scrolling is optimized for touch, but I'm wondering if you could offer some way to enable the same behavior that desktop safari and other browsers allow...

If you set 'pointer-events: none' or 'visibility: hidden' on an element that has a scrollport, then on set 'visibility: visible' or 'pointer-events: auto' on it's descendants, most browsers still allow the scrolling to work enabling experiences like this...

Try on safari desktop -> http://jsbin.com/cujesed/1

In the example, you can scroll the white blocks up from the bottom edge of the screen, filling out more of the screen where their scroll container sits, but when the white blocks are scrolled down to the bottom edge, you are still able to scroll the whole red webpage while your pointer is in the area that would scroll the white blocks if they were scrolled up.

Then try on iOS safari, notice you cannot scroll up on the white blocks. On 'touchstart' I am trying to reset the visibility/pointer-events on the scroll container, which is seen when the background changes to grey, but no scrolling is enabled.

In future versions of iOS Safari could we have a way to do this, leveraging 'native scrolling' instead of writing our own javascript based touch interactions to 'polyfill' the lack of scrolling?

Steps to produce...
1. Go to provided link on iOS Safari -> http://jsbin.com/cujesed/1
2. See how white boxes ('app-tray') sit at bottom of screen with styling of pointer-events:none (or visibility:hidden)
3. Descendants of 'app-tray' are styled with pointer-events:auto (or visibility:visible)
4. Notice how you cannot scroll the white boxes ('app-tray').
5. Go to link on desktop safari and see how you can scroll the white boxes into the screen.

[Radar WebKit Bug Importer]

<rdar://problem/38757252>

[jonjohnjohnson]

Here's an even more reduced test case showing the bug AND a work around, which makes me think my initial belief of this being intentional in iOS was incorrect:

- https://jsbin.com/talomas/quiet
- https://jsbin.com/talomas/edit?html,css,output


Steps to see the differences in the scrollers:
1. Open test case in iOS https://jsbin.com/talomas/quiet
2. Swipe vertically in the pink areas of both the left and right side of the screen, notice it just scrolls the document/body.
3. Swipe vertically on the right side from the striped area, notice it allows for scrolling of the pink background scroller.
4. Attempt the same vertically scrolling in the left side from the striped area. Nothing will get the pink scroller to scroll. It only passes the scrolling events down to the document/body scroller.

Results:
The left side scroller *should accept vertical scrolling interactions on iOS (and always on macOS, even if sometimes it's bugged between being viewed in an iframe or not?) above its striped background children elements.

Expected Results:
Both left and right side scrollers should allows for vertical scrolling from scrolling interactions (touch/mouse) above their striped background children elements.

There are two vertical scrollers at the top of the screen, with pointer-events removed on themselves, but again, with a child element that re-enables pointer-events. The top half of the scrollers scrollport in both, allows pointer-events to pass through, so scrolling there will just scroll the body element of the document. But if you scroll from above the child elements, with striped backgrounds, you *should be able to scroll both scrollers.

The left side scroller, shows the bug where on iOS (and even sometimes on macOS) you cannot scroll.

The right side scroller has horizontally overflowing and scrollable content, just by adding `overflow-x: scroll` to its 'tray-inner' element, and this in itself seems to be the work around to get iOS safari to recognize vertical scrolling on itself for its parent scroller. You shouldn't need to make an element scrollable in an opposite axis in order for it to actually accept scrolling of its parent scroller, especially since this more or less creates just another problem in a user accidentally scrolling that other axis.

I hope this helps describe the problem more clearly. And if not, I can try to record a video of the differences from macOS and iOS.

cc [e-mail]

[Simon Fraser (smfr)]

I still find that test case pretty hard to understand. Please use different colors for the "good" and bad" scrolling areas. Words help.

FWIW, Chrome has the same broken behavior for the left-pink-side scrolling. It works in Firefox.

[jonjohnjohnson]

Created attachment 356417 [details]
Scroll interactions from child scroller on left side scroller only scrolls ancestor. Unlike the right.

[jonjohnjohnson]

I attached a quick video showing vertical touch interactions attempting to scroll vertically from all areas of the original test case, left and right side scrollers with the interaction originating on scroll containers themselves, as well as originating on the striped elements inside the scroll containers, showing the left not working like the right side. That is itself the issue. That they don't behave the same.

The left, only ever "chains" up scrolling the viewport. The right, allows itself to scroll. This is only remedied on the right side scroller by creating a horizontal scroller on that inner element (overflow-x: scroll). This somehow makes it so now the vertical scroller it lives within can actually accept pointer events.

I've updated the case, to highlight the broken behavior with red colors in the left scroller and green colors in the right scroller.

If you inspect the case, you'll see besides color differences, one line of css different for the green/right scroller.

.tray-horz .tray-inner {
overflow-x: scroll;
}

The red/left side scroller should allow itself to be vertically scrolled from an event on the striped element, just as the green/right side scroller. The attached video shows this doesn't happen and is broken in the left.

[e-mail], the original test case I posted here does work in chrome as well as in desktop safari, just not ios safari (http://jsbin.com/cujesed/1), the more isolated case chasing the hack to *fix the broken behavior doesn't work in chrome, like you stated. They seem to have a similar, but slightly different issue: https://bugs.chromium.org/p/chromium/issues/detail?id=909083

Sorry I still have yet to fully grasp a lot of lingo you guys use for the inner-workings of browsers/specs, and though I try to be verbose enough to explain these things, I'm surely both too wordy and not specific enough.

[jonjohnjohnson]

Here's another video which shows the bug on desktop Safari.

http://cl.ly/444ac5407c74

Mouse is hovering different areas of each scroller, attempting to vertically scroll in each area.

Green area, scrolls body. Correct.
Red area, scrolls body. Correct.
Green striped area, scrolls green scroll. Correct.
Red striped area, scrolls body. Incorrect.

Again, the only reason the green striped area is working to scroll the green scroller is because it has an element inside it that scrolls horizontally. I'm only showing this "fix" to highlight how I think the left side should behave, if it wasn't bugged.

[jonjohnjohnson]

Created attachment 356435 [details]
Another test case, that uses :checked pseudo class to show the hack that fixes the in the same scroller.

Here is another test case, showing the difference of what is expected against what is bugged within the same scroll container. I hope this helps.

This test case is bugged on iOS and desktop safari, though again, it may not be exactly the same bug as blinks, regarding pointer-events and scroll containers, as shown in this issues original test case (https://output.jsbin.com/cujesed/1).

[jonjohnjohnson]

One last attempt to try to be even clearer.

When the test case found at https://jsbin.com/talomas/quiet, is accessed within an iframe on safari desktop. Like here https://jsbin.com/talomas/edit?html,css,output, it doesn't exhibit the broken behavior on the left side scroller. Just trying to highlight ways in which it is broken and and ways in which it is not.

And from my original post, I mention use of the visibility property, because any time I attempt its use to replace the pointer-events property (`visibility: hidden` takes the place of `pointer-events: none` and `visibility: visible` takes the place of `pointer-events: auto`) the same exact bug appears.

[Simon Fraser (smfr)]

Created attachment 356447 [details]
Simpler testcase

Scrolling in this testcase is pretty bizarre, and I think it's buggy in all browsers. I would expect no browser to allow scrolling of the "This should not be scrollable" div, but if your mouse is over the left side of it, they allow scrolling.

[jonjohnjohnson]

[e-mail] the attachment 356447 [details] you posted does in fact work as expected for me in Firefox Nightly. Allowing me to scroll the "This should not be scrollable" element from the right hand side as well as the left.

But surely, quite bizarre artifacts you found.

Also, I was under the impression the `all` value for `pointer-events` was solely for SVG, even if behaved as `auto` for non svg compat?

As far as the original original test case UI. It's about allowing something to scroll out onto the screen from a sliver of its content, and while closed, not have scroll events pull it out into view obfuscating scroll interaction for the main view.

I think this is a reasonable ask for this setup of layout/styling?

[jonjohnjohnson]

Also, [e-mail], I do have webRender enabled in my firefox, which historically has made their pointer-events/scrolling behave in a more sane manner.

Bug report reference : https://bugzilla.mozilla.org/show_bug.cgi?id=1456938

[jonjohnjohnson]

Created attachment 356837 [details]
iOS scroll interactions only captured by scroll containers above other scroll containers in z space

Another test case showing the weirdness that motivated originally filing this issue.

Just like in desktop, iOS should not allow the text block to be scrolled when scrolling from red block. It should behave like scrolling interactions on green block, not scrolling text at all.

[jonjohnjohnson]

(In reply to Simon Fraser (smfr) from comment #9)
> I would expect no browser to allow scrolling of the "This should
> not be scrollable" div, but if your mouse is over the left side of it, they
> allow scrolling.

Why is it exactly that you'd expect no scrolling would occur over the right hand side?
All browsers allow for "text selection" to drag that element from the right hand side exposing the elements scrolling mechanism. Is this something you also wouldn't expect? Or do you just think, that a scroll/wheel/gesture shouldn't manipulate it's scrolling mechanism while dragging to select text should scroll it?