Issue metadata
Sign in to add a comment
|
CSS box-shadow on pseudo-elements renders in front of element
Reported by
alf...@xng.io,
Jun 1 2016
|
||||||||||||||||||||||
Issue description
Chrome Version : 53.0.2755.0 (Developer Build) (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: OK - 9.1.1 (11601.6.17)
Firefox: OK - 46.0.1
IE:
What steps will reproduce the problem?
(1) Go to https://jsfiddle.net/ma2rmuwj/ (or any other page with box-shadow on pseudo-elements)
What is the expected result?
The box-shadow appears behind the square
What happens instead?
The box-shadow appears on top of the square, not behind it
Please provide any additional information below. Attach a screenshot if
possible.
Tested Chrome versions affected: latest Dev channel, latest Canary, Chromium build mentioned above.
Screenshot of the jsfiddle is attached.
Probably not relevant, but I first noticed this when visiting inbox.google.com, which makes use of this in a variety of prominent places.
,
Jun 1 2016
,
Jun 2 2016
,
Jun 2 2016
Just did a bit more testing, and the issue didn't appear on my laptop. My desktop has an NVIDIA card, while my laptop uses integrated graphics. It definitely seems to be a GPU-related issue, since the bug does not appear if I turn off GPU rasterization in chrome://flags. The bug also appears in Chrome Beta if I enable the flag. Hope that helps, and let me know if there's anything at all I can do to help pin down the issue.
,
Jun 2 2016
,
Jun 2 2016
Adding CSS label back to confirm something. In my reading of the psuedo-element spec, the psuedo element should be painted in document order. So in this case ::before or ::after should give different output, placing the psuedo element behind or in front of the div respectively. We always paint in front regardless of ::before or ::after. Could the expected paint order be confirmed please? I can't repro the given screen shot on trunk linux with forced GPU rasterization. Can anyone else?
,
Jun 3 2016
Able to reproduce the issue on windows 7,Linux Ubuntu 14.04 using chrome version 51.0.2704.79 and canary 53.0.2754.1 with the below steps 1. Enabled the flag #enable-gpu-rasterization from chrome://flags 2. Go to URL https://jsfiddle.net/ma2rmuwj/ 3.Observed the border line and shadow Please find the attached screen shot for the same.This issue is working fine on Mac 10.11.5. This is regression issue broken in M44.Please find the bisect information as below Narrow Bisect:: Good:: 44.0.2392.0 -- (official build 328239) Bad:: 44.0.2393.0 -- (official build 328439) CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/04d92963d0b324aff0ef9d1db09d3de3890b9cd2..c12a26cb991c224ac29568e3ac0055d247a2cdc5 Blink CL:: https://chromium.googlesource.com/chromium/blink/+log/44daba6..dd90b8c Possible suspect from the above blink CL https://chromium.googlesource.com/chromium/blink/+/5793b970a6d767b9a9201e304f11127cb418811c hendrikw@ Could you please look into this issue if it is related to your change,else please route this to an appropriate dev person. removing the TestConfirmation label as of now ,please feel free to add if required. Thanks,
,
Jun 3 2016
It's possible that this change exposed, but if so, it would be a more general problem with gpu rasterization, and would have happened on mobile devices already. One possible test would be to turn off gpu rasterization completely to see if it fixes the issue. @vmiura, I thought I saw some emails about looking closer at the GPU trigger, you might want to take a look a this one. (btw: I don't work on Chrome anymore.)
,
Jul 7 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 13 2016
,
Dec 19 2016
Can no longer reproduce this. Please refile if you're still seeing it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by alf...@xng.io
, Jun 1 2016