:after CSS rules can affect subsequent, non-targeted :after pseudoelements
Reported by
jam...@netflix.com,
Jul 7 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Navigate to https://jsfiddle.net/6sjmko0h/2/ 2. Observe that the second checkbox does not display correctly on Chrome The first and second checkboxes have the exact same styling targeting them. The difference is that another element is between them, and that element's :after styling is breaking subsequent :after renders. Play around with the Fiddle – if you remove the content of the "searchBar," so that it is just "<div class="searchBar"/>" then the problem goes away. This is a very strange bug! What is the expected behavior? Both checkboxes would render identically. What went wrong? The checkboxes render dirrectly. Did this work before? Yes I'm not sure. It worked last week, then when I got into work this week, my browser must have updated, causing it to break. So a recent version of Chrome stable. Does this work in other browsers? N/A Chrome version: 59.0.3071.115 Channel: stable OS Version: OS X 10.12.5 Flash Version: Shockwave Flash 26.0 r0 This isn't a Webkit bug, since it doesn't happen in Safari. Amusingly, this is one of two related issue. There is another, very similar issue that can cause the checkbox to be offset in the horizontal direction. In my app, all of the checkboxes are offset vertically in this way, but also horizontally. I isolated the vertical offset to be this issue, and I'm still working on isolating the horizontal offset. Perhaps the same change to the way pseudoelements were rendered is causing this problem?
,
Jul 8 2017
Hm, maybe it didn't attach, even though I selected a file before hitting "Save Changes." I'll try again. Let me know if it's showing now (I'm not too sure where it would appear if it uploads successfully).
,
Jul 8 2017
Bisect: 449898 (good) - 449899 (bad), 58.0.3011.0 https://chromium.googlesource.com/chromium/src/+log/09885722..56850c99?pretty=fuller The only CL is r449899 "[SPInvalidation] Use GeometryMapper in PaintLayerClipper for paint"
,
Jul 10 2017
@woxxom: Thanks for the bisect information Able to reproduce the issue using #59.0.3071.115 on Mac 10.12.5, Win 10 and Linux Ubuntu 14.04. Below is the bisect information =============================== CHANGELOG URL ------------ https://chromium.googlesource.com/chromium/src/+log/09885722..56850c99?pretty=fuller Review-Url: https://codereview.chromium.org/2671853003 @chrishtr: Please help in re-assigning the issue to appropriate owner if it's not related to your change. Thanks!!
,
Jul 17 2017
Fix is in code review.
,
Jul 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fb1364df3ad900158e6822cd05d3d1114138058c commit fb1364df3ad900158e6822cd05d3d1114138058c Author: Chris Harrelson <chrishtr@chromium.org> Date: Tue Jul 18 20:07:15 2017 Plumb subpixel accumulation to software ancestor-clips of software transforms. Bug: 740273 Change-Id: I30bed13de22c3edece852c4bae30870e41c535c6 Reviewed-on: https://chromium-review.googlesource.com/575547 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#487572} [add] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/LayoutTests/paint/subpixel/transform-inside-clip-expected.png [add] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/LayoutTests/paint/subpixel/transform-inside-clip-expected.txt [add] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/LayoutTests/paint/subpixel/transform-inside-clip.html [modify] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp [modify] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/Source/core/paint/PaintLayerClipperTest.cpp [modify] https://crrev.com/fb1364df3ad900158e6822cd05d3d1114138058c/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
,
Jul 18 2017
,
Aug 10 2017
This was resolved, but then reintroduced in the latest Chrome.
,
Aug 10 2017
Re comment 9: what version of Chrome are you testing on? What platform/device combo?
,
Aug 10 2017
13" Macbook Pro Chrome Version 60.0.3112.90 (Official Build) (64-bit) macOS Sierra 10.12.6 (16G29)
,
Aug 10 2017
Ah ok. My patch only made it into 61.0.3161.0 beta.
,
Aug 10 2017
Ah, alright. Perhaps it was the horizontal spacing issue with psuedoelements that I mentioned above was fixed, and then regressed. I still need to make an issue for that... Sorry for the noise. |
|||
►
Sign in to add a comment |
|||
Comment 1 by jam...@netflix.com
, Jul 7 2017