Height and overflow=hidden on the last visible element in the document cause big problems with scrolling |
||||
Issue descriptionVersion: 49.0.2623.112 (64-bit) (looks even worse on 52.0.2718.0 canary (64-bit)) OS: Mac OSX El Capitan (mobile emulation), Nexus 5X Marshmallow What steps will reproduce the problem? (1) On desktop Chrome, switch to Nexus 5X emulation (the steps would likewise work on the phone) (2) Open this page: https://www.google.com/amp/www.dailymail.co.uk/femail/article-3572706/amp/Channing-Tatum-left-fits-giggles-interviewed-woman-autism.html (3) Try to touch-scroll. Use touch-scroll specifically, not any other method of scrolling. What is the expected output? Page scrolls well. What do you see instead? Page barely scrolls. It takes few attempts to start scrolling. Explanation: The scrolling page itself is the scrollable iframe. The iframe is styled with `overflow-x: hidden`, which shouldn't by itself affect vertical scrolling. AFAICT, the problem is with the last visible element in this document which looks like this: ``` <div class="puff"> <ul> <li> <a class="bottom" href="..." target="_blank"> <amp-img height="115" src="..." width="154"></amp-img> <span class="pufftext"></span> </a> </li> </ul> </div> ``` This last `<li>` is styled as following: ``` .puff li { ... height: 116px; } ``` However, this element needs more than `116px` height. And this is what causes the scrolling problem. Just adding `overflow: hidden` to this last `<li>` fixes the problem: ``` document.querySelector('.puff li:last-child').style.overflow = 'hidden'; ``` Alternatively, setting `height: auto` on this `<li>` also fixes the problem.
,
May 5 2016
I observe that the bug happens only when you change scrolling direction, and then a giant scrollbar appears, overlapping the normal-sized scrollbar which is still fading out. The giant scrollbar starts at the bottom of the fixed-pos (I can see a gap), whereas the normal scrollbar can go under the fixed-pos and no longer be seen. So there are two scrollable sublayers here, one slightly larger than the viewport, and one the size of the document, and we only bubble the scroll up the hierarchy when the child didn't scroll.
You have CSS within the iframe stating:
html, body { overflow-x: hidden!important; }
The slightly-larger-than-viewport sized scrollable layer comes from the <body> element, and the full-sized document scroller is from the <html> element. Injecting "body { overflow: hidden!important; }" fixes it by letting the <html> element be the only one scrolling.
I'm still not sure whether or not to consider Chrome's behavior here a bug, but I think in any case that would probably be a sufficient fix for you, as I believe you only intended to have one scrollable layer?
(Note I'm in Seoul this week so I'll be slow in replying further, cc'ing some other folks who can help.)
,
May 5 2016
Adding overflow-x: hidden forces overflow-y to be computed to auto on both the body and html elements so they both (potentially) get a scrolling box. However, there is something subtle going on with the bottom element. The body element is height: auto so it should grow to enclose all its content. It seems that padding in the visible overflow of a child element doesn't apply to the parent content but it does cause the parent to have overflow. This is what establishes <body> as a scrolling box. I've reduced this down to a minimized test case where it's easier to see what's going on: http://bokan.ca/bugs/609161.html This may actually be spec compliant, Firefox behaves the same way here. The reason it feels particularly bad in Chrome on the site in the original report is our scroll chaining behavior changed recently, we don't chain touch scrolls past the first scrolled target. That means that as soon as you start scrolling a box, that's the only box that will scroll until the gesture ends. +eae@,szager@ to make sure this isn't a layout bug. If this is expected behavior on the layout side, I'm don't think there's anything on the Chrome side to do, this seems like a bad edge-case for the scroll chaining but it's easily fixed using overflow:hidden.
,
May 5 2016
I've just checked that Edge works the same way so I think the layout issue is standard behavior.
,
May 5 2016
Thanks bokan, that matches my expectations too.
,
May 5 2016
Thanks a lot for the explanation - let's close this bug then?
,
May 5 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by dvoytenko@google.com
, May 4 2016