Created attachment 459708 [details] 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.
Created attachment 459709 [details] video_testcase Video for the testcase.
This is a Safari feature, not a WebKit feature, so should be filed using Feedback Assistant (sorry!).
Done, thank you!
(In reply to Bruno Stasse from comment #3) > Done, thank you! rdar://93891068 for anyone who comes across this inside Apple (FB10027355)