Composited-scrolling PaintLayers should not always include clip of the scroll for overlap testing
Reported by
jackc.zh...@airbnb.com,
Apr 5 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Example URL: https://www.airbnb.com/s/San-Francisco--CA--United-States Steps to reproduce the problem: 1. On hidpi/retina screen, go to https://www.airbnb.com/s/San-Francisco--CA--United-States 2. Scroll down left pane 3. Hover over an image What is the expected behavior? The elements over the image (heart in top right, price box in the bottom left, carousel arrows) are always visible when scrolled into view. What went wrong? The overlay elements are hidden until the user hovers over the image. I've attached a gif showing the bug. Using Chrome stable, this only occurs when the browser is open on hidpi screen, e.g. 4k display on Linux or Macbook Retina built-in screen. The same tab dragged to a normal resolution screen (e.g. mac cinema display) doesn't have this problem. Interesting, this problem starting occurring consistently on all screens in Chrome Canary (51.0.2700.0). I tried to create a simple test case that isolates the problem, but unfortunately it seems like it's triggered by multiple conditions, maybe the custom font, icon font, and large number of layers. Does it occur on multiple sites: No Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 49.0.2623.110 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0
,
Apr 26 2016
The problem was triggered by a backface-visibility css property on the image.
,
Jul 13 2016
,
Jul 13 2016
I'm not reproducing on M52 or M54, so if it's only M51 then we probably won't fix it. Is anyone on the team aware of changes related to backface-visibility? Re comment #2, did you modify the site once you found the problem? i.e. should we still be able to see it?
,
Jul 13 2016
I think the bug reporter might have fixed the airbnb site per comment 2.
,
Jul 13 2016
Thanks for getting back to me. I've already removed the problematic css on
the site. The bug still exists when manually adding back the styles. Here's
a js snippet I ran in devtools to mimic the old css:
Array.from(document.querySelectorAll('.media-photo.media-cover')).forEach(elem
=> { elem.style.backfaceVisibility = 'hidden'; });
,
Jul 13 2016
Thanks for the good feedback. We can try to repro with the additional JS. This looks like an invalidation problem, given that we correctly repaint when we have another reason to (the hover).
,
Aug 25 2016
Reproduced on Linux with --enable-prefer-compositing-to-lcd-text. Reduced test case attached. It seems that we fail to promote the green div to a layer because we fail to detect overlap of the red div and the green div when they are not in the visible area of the scrollable div. chrishtr@ can you take a look?
,
Oct 14 2016
This is a bug in the overlap testing machinery in CompositingRequirementsUpdater.
,
Oct 18 2016
The bug is that the overlap test incorrectly clips elements which are not visible at present but are within the overflow region of a composited scroller.
,
Oct 18 2016
,
Oct 18 2016
,
Oct 18 2016
https://bugs.chromium.org/p/chromium/issues/detail?id=347205#c6 has the same suggestion that I am trying to implement in https://codereview.chromium.org/2425873005. The remaining difficulty is to revert to applying the clip for PaintLayers that are not children of the composited scroller.
,
Oct 21 2016
,
Oct 21 2016
Issue 470260 has been merged into this issue. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by spqc...@chromium.org
, Apr 5 2016