New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 666918 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 660735
Owner:
NOT IN USE
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

PseudoElement+PointerEvents+ClassList rendering problem

Reported by aurel...@gmail.com, Nov 18 2016

Issue description

Chrome Version       : 54.0.2840.99
Other browsers tested:
     Safari: OK (Safari 9, iOS 9.3.1)
    Firefox: OK (Firefox 50)
         IE: OK (IE11)

What steps will reproduce the problem?

(1) Use the following CSS:
<style>
    div::after {content: "bar";}
    div.locked {pointer-events: none;}
    div.locked::after {color: red;}
</style>

(2) Use the following markup:
<div onclick="this.classList.add('locked');">foo</div>

(3) Click on the div.

What is the expected result?
The suffix "bar" becomes red.

What happens instead?
The suffix "bar" remains black.

Notes:
- this only happens when all 3 conditions are met (pseudo-element, pointer-events, dynamic class)
- this seems to be a rendering bug, because if you just tinker with the console a bit (i.e. you check and then uncheck a CSS declaration), the bug disappears.



 
Components: Blink>CSS
Labels: -Pri-3 M-54 Needs-Triage-M54 Pri-2
Thanks for the report. Would you mind providing the a sample html testcase for the ease of finding regression.

Comment 2 by aurel...@gmail.com, Nov 18 2016

Here is my testcase, as described above.
Bug.html
304 bytes View Download

Comment 3 by samli@chromium.org, Nov 20 2016

Labels: Needs-TestConfirmation
Doesn't reproduce on Mac 57.0.2926.0 Canary. Reproduces on Mac 54.
Cc: rbasuvula@chromium.org
Labels: -Needs-TestConfirmation -M-54 hasbisect-per-revision M-55 OS-Linux OS-Mac OS-Windows
Owner: r...@opera.com
Status: Assigned (was: Unconfirmed)
Tested in chrome stable #54.0.2840.98 and beta #55.0.2883.59 on Mac 10.11.6 and able to reproduce the issue. Not able to reproduce the issue in canary #57.0.2926.0 and dev #56.0.2922.1. So providing the reverse bisect details.

Below are the Bisect Details:

Bisect Info:
=============
Good Build: 56.0.2916.0 (Revision- 431463)
Bad Build: 56.0.2915.0 (Revision- 431137)


Bisect URL:
=========== 
You are probably looking for a change made after 431429 (known good), but no later than 431430 (first known bad).

CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/099ae81b169f933218d587a7192d64444d282b04..998f4790884a34c5ac5167876a13b7cb7495a617


From the CL above, assigning the issue to the concern owner. Probably this change could have fixed the issue.

@ rune : 
------------------
Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Review-Url: https://codereview.chromium.org/2492783002

Note: Able to reproduce the issue in Ubuntu 14.04 and Win 10.0

Comment 5 by r...@opera.com, Nov 22 2016

Mergedinto: 660735
Status: Duplicate (was: Assigned)

Comment 6 by r...@opera.com, Nov 22 2016

Are you sure this didn't work in 55.0.2883.59? That was the version the fix was verified against.

Sign in to add a comment