Vertical scrollbar appears above elment with position:fixed
Reported by
qbo...@gmail.com,
Mar 12 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Example URL: http://codepen.io/anon/pen/oxzvbQ Steps to reproduce the problem: 1. visit http://codepen.io/anon/pen/oxzvbQ 2. observe there is a scrollbar which covers partially the word "close" 3. try to comment any of the three lines: a) 14. -webkit-backface-visibility: hidden; b) 17. z-index:0; c) 18. position:relative; and observe that this causes the scrollbar to move to the background (underneath the word "close"). What is the expected behavior? Latest Firefox and the latest IE do not cover the word "close" with a scrollbar. The .popup covers the scrollbar in them. I would expect the same with Chrome. I would expect the behaviour to be the same regardless of using -webkit-backface-visibility:hidden. I would expect that a scrollbar which is "belongs" to a different element (in this case probably it is a scrollbar of .app) not to be displayed on top of a fixed element. I would expect that a scrollbar which for some reason appears to visible and enabled, should actually work when I use mousewheel or drag it with mouse. What went wrong? In Chrome the scrollbar appears on top of everything and appears like it is enabled (based on it's colors) but actually I can not scroll it (neither using mousewheel nor by dragining), and when trying to inspect this area using dev tools it seems that this part of screen is being considered to belong to ".popup" or ".close". Moreover I can cause the scrollbar to appear below the surface of .popup by simply removing -webkit-backface-visibility:hidden directive which seems to support a hypothesis that this is some rendering artifact, and not a real UI control. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? Yes I think it used to work well a month ago (but can not prove it) Does this work in other browsers? Yes Chrome version: 48.0.2564.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0
,
Mar 14 2016
,
Mar 14 2016
,
Mar 23 2016
In highdpi the scroller, popu and spp are separate layers and order correctly. In lowdpi they all appear in a single layer and stack incorrectly. It appears there is a paint bug after all, Chris? The hit testing code seems to know which is in front, so the scrollbar is not reactive.
,
Mar 23 2016
My work in progress patch for https://bugs.chromium.org/p/chromium/issues/detail?id=381840 fixes this, but will only fix it for solid backgrounds on the scrolling content. As is suggested by the lowDPI/highDPI difference, the issue is in getting the wrong layer ordering when the scrolling content is not promoted.
,
Jan 19 2017
No longer reproduces. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dstockwell@chromium.org
, Mar 14 2016