Scrollbar never appears again after animated spinner renders inside scrollable element
Reported by
etlov...@gmail.com,
Jan 26 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Example URL: See attached bug.html file Steps to reproduce the problem: 1. Be on OS X, with the OS "Show scroll bars" setting (System Preferences -> General) set to "Automatically based on mouse or trackpad". 2. Open the attached bug.html file. 3. (Scroll in the scrollable element. Note that the scrollbar appears, as expected.) 4. Click the button at the top of the scrollable element. 5. Wait for the spinner to disappear. 6. Scroll in the scrollable element. What is the expected behavior? The scrollbar should be visible, just as in step 3. What went wrong? The scrollbar does not appear. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? Yes Chrome version: 64.0.3282.119 Channel: stable OS Version: OS X 10.13.3 Flash Version: This bug is present for me in both Chrome 64.0.3282.119 (current stable) and 66.0.3329.1 (current or near recent Canary). This works as expected for me in the following other browsers: * Firefox 59.0b3 * Safari 11.0.3 (13604.5.6) * Safari Technology Preview Release 48 (Safari 11.2, WebKit 13606.1.2.2) I'm on OS X High Sierra 10.13.3.
,
Jan 27 2018
,
Jan 30 2018
,
Jan 31 2018
Able to reproduce this issue on Mac 10.12.6 and mac 10.13.1 using chrome reported version #64.0.3282.119 and latest canary #66.0.3334.0. This is a non-regression issue as it is observed from M60 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Feb 1 2018
Can definitely reproduce issue. Layers in devtools seem the same. Not sure what is going on.
,
Mar 28 2018
This appears to be a compositing issue somewhere in GraphicsLayerTreeBuilder. The scrollable area still has a vertical scrollbar layer and the PaintedScrollbarLayer in CC is still alive but we don't sync it at the next TreeSync so the PaintedScrollbarLayerImpl is removed. It looks like we lose the overflow controls host layer on the scroller.
From what I can tell, when the animation ends we:
1) Detach the 'outer' scroller's overflow controls host layer at GraphicsLayerTreeBuilder::Rebuild (with layer == 'spinner' PaintLayer) here:
child_layers.push_back(layer.ScrollParent()
->GetCompositedLayerMapping()
->DetachLayerForOverflowControls());
2) Further up in the stack with GraphicsLayerTreeBuilder::Rebuild at layer == 'outer' PaintLayer, we call SetSublayers on the LayoutView's scrolling contents layer - the children we set now include the overflow controls host layer of the "outer" scroller. The OCHL is now attached to the layout view's scrolling contents.
3) On a later pass, we end up clobbering the overflow controls host layer from the LayoutView's scrolling contents layer so it's totally removed from the tree.
4) When the tree is synced to the impl thread, the scrollbar layers and OCHL are removed
I'm not sure where the bug is but I suspect #1 - it probably doesn't mean to detach the container's overflow controls. Over to compositing folks to figure out a fix.
,
Mar 29 2018
Odd that something like this would be Mac only. But so many scrollbar issues are due to Mac system scrollbar behavior. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by meh...@chromium.org
, Jan 26 2018