[Webkit-unassigned] [Bug 240861] New: Scrolling over horizontal scroll containers triggers Safari iOS UI shift

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 24 00:54:40 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=240861

            Bug ID: 240861
           Summary: Scrolling over horizontal scroll containers triggers
                    Safari iOS UI shift
           Product: WebKit
           Version: Safari 15
          Hardware: iPhone / iPad
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Scrolling
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: augus.dupin at gmail.com
                CC: simon.fraser at apple.com

Created attachment 459708

  --> https://bugs.webkit.org/attachment.cgi?id=459708&action=review

testcase

Before Safari 15, iOS Safari’s UI would shift (i.e. collapse/reveal) based on body scrolling. Since Safari 15, iOS Safari’s UI shifts based on vertical touchmoves.

Initially, touchmoves anywhere on the page were taken into account to shift the UI. As a consequence, scrolling up/down inside an element scroll container would cause the browser UI to shift. It was often a strange behaviour, as the element didn’t seem connected to the page, and it didn’t feel natural to see the browser UI move when interacting with it.

This was also problematic when a scroll container was in position: fixed at the bottom of the viewport, because when the UI shifted it would push up/down the scroll container, causing a jarring user experience. This was even more problematic when such scroll container size was based on the viewport height, because it was then susceptible to cause layout shift during scrolling, and sometimes cause bugs.

Thankfully, the behaviour has been improved around Safari 15.4 I believe. Now, when the vertical touchmoves are initiated on a vertical scroll container (other than the body), then the UI does not shift. This is much better in most cases. However, it only works when the touchmoves are initiated on *vertical* scroll containers, and not horizontal ones, therefore it leaved out some cases:

- when initiating horizontal scrolling inside a horizontal scroll container, and then moving the finger vertically, the browser UI will shift;
- when a horizontal scroll container is nested inside a vertical scroll container, when initiating vertical scrolling over the horizontal scroll container, the browser UI will shift.

Steps to reproduce with the testcase in Safari iOS:

- scroll vertically the body by initiating touch over the [body] text (blue)
- see the browser UI shift, as expected

- scroll vertically the [y-scroller] by initiating touch over the [y-scroller] text (purple)
- see the browser UI stay still, as expected

- scroll vertically the [y-scroller] by initiating touch over the [x-scroller] text (green)
- see the browser UI shift, which is UNEXPECTED

- scroll horizontally the [x-scroller] by initiating touch over the [x-scroller] text (green)
- then, without lifting the finger, move it vertically
- see the browser UI shift, which is UNEXPECTED

- scroll vertically the [y-scroller inside x-scroller] by initiating touch over the [y-scroller inside x-scroller] text (orange)
- see the browser UI stay still, as expected

As we can see, unexpected behaviours happen when scroll is initiated over a horizontal scroll container, because then the browser UI shifts.

It would be more appropriate and safe not to trigger the browser UI shift when touchmove is initiated over any type of element scroll container, whether it is vertical or horizontal. This should prevent all unexpected behaviour observed above.

Another bug related to the browser UI shift with touch-action: https://bugs.webkit.org/show_bug.cgi?id=233417 - touch-action doesn't prevent the Safari UI from collapsing.

Please let me know if you need more information.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220524/042d0217/attachment-0001.htm>


More information about the webkit-unassigned mailing list