Bug 212439 – Horizontally scrolling elements are broken when revealed by toggling visibility

• Status: RESOLVED
• Resolution: FIXED
• Component: Scrolling

Created attachment 400388 [details]
minimal test case

The expected behavior for scrolling is that when beginning a swipe in a horizontal direction on an element that can scroll horizontally, the element scrolls and vertical page scrolling is locked. (Sorry, I'm not sure if there's a technical term for this.) The buggy behavior is that vertical page scrolling is not locked, so that swiping diagonally or in a circle (for example) will scroll both the carousel and the page simultaneously, which isn't disastrous but is quite annoying.

To reproduce, open the attached HTML file in iOS Safari. There are three horizontally scrolling elements on the page, two of which are initially hidden. The first, unhidden scrollable displays the expected behavior. The second and third scrollables, after being unhidden, display the buggy behavior. There appear to be three requirements:

1. The scrollable must be initially hidden. visibility: hidden triggers the bug; I think display: none does not.
2. The scrollable must have certain styles set. position: relative and -webkit-overflow-scrolling: touch both seem to trigger the bug.
3. The page must have a touchmove event handler set.

If the page does not have a touchmove handler, I see different buggy behavior where the second and third scrollables don't scroll at all. (The first is still unaffected.) Also, the scrollable does not have momentum even if -webkit-overflow-scrolling is set.

This bug appeared in iOS Safari 13.4.1 and was not present on 13.3.1.

[Radar WebKit Bug Importer]

<rdar://problem/63739559>

+1

I've also noticed the issue where horizontal scrolling does not occur when I do not have a touchmove handler and I change the visibility of my element from "hidden" to "visible".

This becomes more problematic when needing to use "visibility: hidden" to ensure screen readers and other assistive technology do not see the element, and then setting the element to "visibility: visible" when a user should be able to interact with it (eg. hiding the scrollable element inside of a collapsable menu).

Are there any known work around for this until it is fixed?

[Simon Fraser (smfr)]

In your testcase, I see that the second scrollable doesn't get momentum, which explains why a vertical movement in it scrolls the page. I think that's a bug.

The third scrollable always behaves as expected. I'm testing iOS 13.5 on iPad.

[Simon Fraser (smfr)]

I also see some issues on macOS. Will investigate.

[Simon Fraser (smfr)]

I think the bug is that creating composited overflow depends on m_hasCompositedScrollableOverflow, but nothing updates that when visibility is toggled (computeScrollDimensions() only happens on layout).

[Simon Fraser (smfr)]

And canUseCompositedScrolling() explicitly checks visibility.

[Simon Fraser (smfr)]

Created attachment 401387 [details]
Patch

[EWS]

Committed r262774: <https://trac.webkit.org/changeset/262774>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 401387 [details].