Bug 153852 - <body> with overflow:hidden CSS is scrollable on iOS
Summary: <body> with overflow:hidden CSS is scrollable on iOS
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: iPhone / iPad iOS 10
: P2 Normal
Assignee: Nobody
URL: https://github.com/w3c/csswg-drafts/c...
Keywords: HasReduction, InRadar
Depends on:
Blocks: 159753
  Show dependency treegraph
 
Reported: 2016-02-03 18:58 PST by Chris Rebert
Modified: 2018-05-14 15:03 PDT (History)
16 users (show)

See Also:


Attachments
Testcase demonstrating the problem (8.37 KB, text/html)
2016-02-03 18:58 PST, Chris Rebert
no flags Details
GIF video demonstrating the bug (885.72 KB, image/gif)
2016-02-04 01:38 PST, Chris Rebert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Rebert 2016-02-03 18:58:32 PST
Created attachment 270621 [details]
Testcase demonstrating the problem

Applying `overflow: hidden` to the `<body>` should make it non-scrollable.
This works correctly on OS X Safari, but doesn't work correctly on iOS Safari.

Original Bootstrap issue:
Lost to the sands of time, but https://github.com/twbs/bootstrap/issues/14839 is relevant & popular.
See also http://getbootstrap.com/getting-started/#overflow-and-scrolling

Steps to reproduce:
1. Open the attached testcase in iOS Safari.
2. Tap the "Launch demo modal" button.
3. A yellow box with text appears.
4. Scroll the yellow box to its bottom, where there are "Close" and "Save changes" buttons, and lift your finger off the screen to ensure that the scroll gesture ends.
5. Attempt to scroll the yellow box further downward (which is to say, apply a "fling upward" gesture to the yellow box).

Actual result:
The <body> underneath the yellow box scrolls downward.

Expected result:
The <body> should not scroll (just like on OS X Safari).
Comment 1 Chris Rebert 2016-02-04 01:38:35 PST
Created attachment 270644 [details]
GIF video demonstrating the bug
Comment 2 Simon Fraser (smfr) 2016-03-22 16:15:42 PDT
I would be concerned about changing behavior here, because it would cause content which has been reachable on earlier iOS versions to become unreachable.
Comment 3 Chris Rebert 2016-03-22 17:21:11 PDT
Android Chrome already made the behavior change and blazed the trail here:
https://bugs.chromium.org/p/chromium/issues/detail?id=175502

They tracked broken sites in https://bugs.chromium.org/p/chromium/issues/detail?id=444581 (and its dupes).
They communicated with several sites and got some to fix their CSS.

In comments 24-25 & 28, they acknowledge some breakage, but don't think there's enough of it to justify switching back:
https://bugs.chromium.org/p/chromium/issues/detail?id=444581#c24
https://bugs.chromium.org/p/chromium/issues/detail?id=444581#c28

I couldn't find any signs of any subsequent revert.

----

If WebKit were to disagree with Chrome's analysis and fear too much breakage,
what would be the path forward?
A new "yes, I really truly want 'hidden' here!" value for the CSS 'overflow' property?
Comment 4 Eric Allam 2016-07-12 04:42:00 PDT
This bug has recently become a problem for a project I'm working on where we are trying to implement a chat interface, with a header element that acts like a navigation bar, and a footer element that includes a text field, with a chat container which includes the chat messages that should be able to scroll. I know this isn't a reduced test case but we have put together a stripped down version of the chat on JSBin which demonstrates this problem too:

http://jsbin.com/ruyito/edit?html,css,output
Comment 5 Chris Rebert 2016-12-04 21:54:42 PST
(In reply to comment #2)
> I would be concerned about changing behavior here, because it would cause
> content which has been reachable on earlier iOS versions to become
> unreachable.

Based on https://github.com/w3c/csswg-drafts/issues/666#issuecomment-257889984 ,
should I assume your opinion has changed?
Comment 6 Simon Fraser (smfr) 2016-12-04 23:03:23 PST
After https://trac.webkit.org/changeset/194667 I am cautious about changing iOS <body> overflow:hidden behavior.
Comment 7 Marcelo Freitas 2017-08-14 13:39:23 PDT
Hi guys, do you have any new about this issue? I am facing similar behavior and I would like to know if is there any solution or workaround!
Comment 8 Sameera 2017-08-15 03:44:22 PDT
I'm having same issue. I have find solution with adding class to body with the style position:fixed. But doing that page scroll to the top.

Any other solutions?
Comment 9 David Bokan 2018-03-08 11:09:40 PST
smfr@, do you have a list of pages you saw affected by this we could check again?

I believe iOS WebKit is the only engine that doesn't respect `overflow: hidden` on body so it'd be great for interop if this could be fixed. FWIW, Chrome has had this behavior for several years now and I haven't heard of it causing issues lately. Perhaps sites have been fixed to take it into account by now.
Comment 11 David Bokan 2018-03-09 09:11:10 PST
Thanks smfr@, I've looked into each case. It seems they fall into one of three buckets (mainly using 6S iOS 9):

No overflow: hidden today - site was fixed:
  https://translate.google.dk/translate?hl=da&sl=en&u=http://www.wikihow.com/&prev=search
  Pages on https://surf.miracosta.edu
  (Apple developer documentation) https://developer.apple.com/documentation/ appears fixed

Overflow(-x): hidden still there but site works correctly in both Chrome and Safari (if overflow: hidden were respected).
  https://books.google.com.mx/books?id=vCMIOfrbYrAC&pg=PA83&dq=Funciones+inyectivas,+suprayectivas+y+biyectivas&ei=AiCHSvDONqbKyQTEhO2fDg#v=onepage&q&f=false
    - Appears intentional and correct - scrolling should occur only on the subscroller
    - Safari allows scrolling main frame a little which actually feels wrong since it shifts the UI out of view
    - Respecting overflow: hidden would actually improve the UX here
  https://mobility.agbar.net/mobility-server/
    - There doesn't appear to be any scrolling on the page.
    - Page loads fully zoomed out
    - overflow: hidden commented out but would work regardless, there's no scrolling on the page
  http://www.arnb.org/Festivals.php
    - overflow-x: hidden - there should be no horizontal scrolling
    - Works correctly, all page content is reachable

Problematic on Safari (all work correctly in Chrome):
  http://archives.nyphil.org/index.php/artifact/63041fe8-4b51-4f96-ae82-e40bccf152cd/fullview#page/1/mode/2up
    - No viewport meta
    - Chrome loads the page zoomed out fully so everything is visible
    - Safari iOS 9 locks the page to zoomed in if overflow: hidden is on. When I turn it off using inspector I can zoom out
  desktop version of live.com/hotmail.com/outlook.com
    - Works correctly in Chrome Android
    - There is overflow-x: hidden
    - I'm guessing Safari loads zoomed in because, even in request desktop site, it respects the viewport <meta> which has initial|min|max-scale: 1? Or perhaps related to overflow: hidden as above.
  https://support.eadocsoftware.com
    - No viewport meta
    - Better on Chrome because Chrome sizes layout viewport to match content width, loads zoomed out - the rest is just pinch zoom
    - Why doesn't Safari allow zooming out?
    - iOS 9 loads zoomed in - iOS11 loads zoomed out like Chrome
  1. Open http://output.jsbin.com/sagowo in iOS 9 Safari.
  2. Tap the blue button to make the Bootstrap modal dialog appear.
    - Works correctly in Chrome
    - Chrome shows the page zoomed out
    - No viewport meta tag
    - Why is safari zoomed in so much? Doesn't allow zoom...
    - iOS 11 works, loads zoomed out

In all the problematic cases it looks like the issue is that Safari loads the page zoomed in and then can't scroll because of overflow: hidden. Was this tried before Safari shipped the visual/layout viewport model? Having the split viewport makes these issues quite tractable; Chrome seems to handle these cases rather gracefully so let me explain what we do:

The layout viewport is sized to cover the entire content width. In the case of a desktop page where we fallback to the 980px initial containing block, the layout viewport will be 980px wide. When the page loads, Chrome zoomes out to the minimum possible scale so the visual viewport will match the layout viewport on load. 

overflow: hidden applies only to the layout viewport scrolling. If the user zooms in, they can still pan around but the layout viewport will not scroll from it's original position. This matches the behavior on desktop. If a page is broken in Chrome Android, it's likely also broken on a desktop browser because the layout viewport operates analogously to the browser window.

When you shipped this did you already have a visual/layout viewport? Did overflow: hidden apply only the the layout viewport. Safari on iOS11 loads all the problematic cases zoomed out  just like Chrome so just marking the layout viewport overflow: hidden wouldn't break any of them.
Comment 12 Simon Fraser (smfr) 2018-03-12 13:14:33 PDT
I don't think we had layout/visual viewports when we tried this before.
Comment 13 Radar WebKit Bug Importer 2018-03-21 11:18:10 PDT
<rdar://problem/38715356>