Able to pan on Android if content width greater than screen size, despite html element having overflow:hidden
Reported by
wisniews...@gmail.com,
Feb 7 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: Steps to reproduce the problem: Try panning around in the attached testcase in Chrome for Android. What is the expected behavior? Should not be able to scroll/pan around, due to the html element having overflow:hidden. What went wrong? Can use touchscreen to pan around despite overflow:hidden. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: Flash Version: Shockwave Flash 24.0 r0 This only happens when the content's *width* is greater than 100% of the device viewport. (If you set width:100% instead of 2000px, then you cannot touch-pan; if only the height is too tall, panning is still disallowed as expected). I'm uncertain if this is an intentional quirk/hack for site usability, but feel this is an web compatibility issue which should be ironed out between browsers if the behavior is deemed desirable. For instance, desktop Chrome disallows scrolling, and Firefox for Android disallows touch-panning as one would probably expect. (Note I have no touchscreen to confirm whether this is related to all Blink versions when using touchscreens, or just related to the Android builds). Note that this was discovered while investigating webcompat.com issue #4005 , as it is causing www.goldenpaints.com to be able to scroll on Android, despite the CSS informing the browser to disallow it (which is what leads me to believe it's an intentional quirk for usability).
,
Feb 8 2017
Can anyone in style team confirm this is a bug or an expected behavior?
,
Feb 9 2017
Seem like a layout/scroll issue, redirecting for triage.
,
Feb 9 2017
The equivalent issue at Mozilla is at: https://bugzilla.mozilla.org/show_bug.cgi?id=1336346 Note that Firefox currently blocks panning which makes some sites difficult to use. The Web compatibility team was wondering if it would be necessary to copy the current behavior of Chrome on Android (in violation of the specification.) There are arguments on both side.
,
Feb 9 2017
,
Feb 9 2017
Chrome does honour the overflow: hidden property on <html>/<body> but the behavior can be tricky to understand in cases like this. What's going on: -Because the content is wider than the viewport, we expand the layout viewport to encompass the whole content width. We need to do this so that the user can zoom out to see the whole page. -Because the layout viewport is expanded, it has no scrolling. Layout viewport is the regular kind of scrolling you'd see on a desktop or unzoomed mobile site. -What you're seeing is visual viewport panning which doesn't respect the overflow property (since it's panning within the layout viewport, not the page content). To see this more clearly, remove the initial-scale=1.0 attribute on the viewport meta. You'll now see that the page is loaded zoomed out and you can't scroll horizontally. What you're seeing with initial-scale is as if you zoomed into an "unscrollable" page and you can pan around. This is expected. Authors can use minimum-scale=1 to cap the size of the layout viewport so you'd get the expected behavior. Interop regarding viewport meta is known to be painful due to many quirks and different zoom implementation between all the browsers. This might become more tractable once Safari and Firefox ship a "virtual viewport" model of pinch-zoom. In any case, this is working as intended so I'm closing it. Happy to discuss/explain further if needed. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Feb 8 2017