[Webkit-unassigned] [Bug 153852] <body> with overflow:hidden CSS is scrollable on iOS

Wed Sep 25 05:49:06 PDT 2019

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

--- Comment #37 from Bruno Stasse <augus.dupin at gmail.com> ---
While trying to create testcases to show when body scroll is not prevented in standalone mode, I noticed that the behaviour is not the same depending on the viewport meta-tag (`width`, `user-scalable`, `viewport-fit`, `shrink-to-fit`, etc) added to the HTML, even in Safari. Even more problematic and surprising, I was able to get different behaviours *with the same code*. Depending on where you come from, or the time of the day — I have no idea —, in Safari in portrait mode, I was able to:
- totally prevent body scrolling, even when the UI is hidden
- have scroll prevented only when the UI is visible
- have scroll not prevented at all whether the UI is visible or not.

I would like to be able to be more precise and provide testcases, but unfortunately the results of my tests were changing for no apparent reasons and therefore cannot. Creating a simple HTML page where you can scroll the body and switch overflow auto/hidden on the body and change the viewport metatag should give you a sense of what it is like.

The situation is therefore even more chaotic and unpredictable than before, as depending on situation the scroll might or might not be prevented. I understand the will to let the user reveal the browser UI with scroll at all time, as this is the primary way to make that happen, and the user is used to it. However, this cannot be done at the prejudice of the UX within web pages. Not being able to able to block the body scroll reliably in all situations makes websites and web applications look buggy, and ruin Safari's users experience, making Safari look bad.

For the reasons mentioned before, the current patch cannot be considered as solving the bug, since unfortunately it doesn't even match the design decision that you mention, Simon Fraser. To recapitulate, we have:

In Safari:
- in portrait mode: scroll might or might not be prevented, whether the UI is fully visible or not, depending on the viewport meta-tag
- in landscape mode: scroll is totally prevented, whether the UI is fully visible or not

In in-app browser (tested in Twitter's):
- Scroll is totally prevented, whether the UI is fully visible or not
(I haven't tested with different meta-tags here, the results might change)

In standalone mode:
- Scroll might or might not be prevented, depending on the viewport meta-tag

Different options are available here, which allow to preserve the browser UI experience as well as web pages experience. Here are those I think the best and most simple:

1) Prevent body scrolling at all time when the body is set to `overflow: hidden` and, as suggested by Davison, consider that making the browser UI appear by tapping the address bar or the bottom of the viewport is enough *just like it is in the new "hide toolbar" feature which landed in iOS 13*.

2) Prevent body scrolling at all time when the body is set to `overflow: hidden` and, *as it is the case when the body is set to `position: fixed`*, display the browser UI fully as soon as the body is set to `overflow: hidden`, and leave it that way til it is set to something else. This is what Chrome on iOS does, and it works very well. Instead of blocking the browser UI collapsed (which you want to avoid), it blocks it open when the body cannot be scrolled.

3) Prevent body scrolling at all time when the body is set to `overflow: hidden` and, as suggested by shrpne, show and hide the browser UI on the user swipes without scrolling the page. Not sure how this would feel however.

The best and fastest to implement solution is probably the second one. Doing that should resolve all problems for everyone.

-- 
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/20190925/ceb8e368/attachment.html>