New issue
Advanced search Search tips

Issue 594333 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Vertical scrollbar appears above elment with position:fixed

Reported by qbo...@gmail.com, Mar 12 2016

Issue description

UserAgent: 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
 
Components: -Blink Blink>Layout>Scrollbars Blink>Paint
Status: Available (was: Unconfirmed)
Components: -Blink>Paint Blink>Compositing
Components: Blink>Paint
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.


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.

Comment 6 by e...@chromium.org, Jan 19 2017

Status: WontFix (was: Available)
No longer reproduces.

Sign in to add a comment