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

Issue 778631 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Not on Chrome anymore
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Transitions in conjunction with :not CSS selector cause div to remain hidden when upgrading Chrome from v61 to v62

Reported by gabi.rad...@gmail.com, Oct 26 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

Steps to reproduce the problem:
1. Define the following styles:

#container div {
  -webkit-transition: all 0.5s;
  transition: all 0.5s;
}

#container.collapsed :not(a) {
  visibility: hidden;
}

2. Create a container div: <div class="collapsed">
3. Inside the container create another div (hidden section) and an anchor
4. Remove the collapsed class on anchor click (see the attached test case)
5. Click the anchor

What is the expected behavior?
The hidden div inside the container should be displayed

What went wrong?
The div remains hidden

Did this work before? Yes 61.0.3163.79

Does this work in other browsers? Yes

Chrome version: 62.0.3202.62  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 27.0 r0

The code behaves correctly in IE 11, Firefox 56 and Edge 38.
You can also find the code snippet that reproduces the problem at the following address: https://codepen.io/gabi922/pen/mBNQjd.
 
testcase.html
627 bytes View Download
Labels: Needs-Bisect Needs-Triage-M62
Cc: manoranj...@chromium.org sc00335...@techmahindra.com r...@opera.com
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET M-62 OS-Linux OS-Mac Pri-1
Owner: treib@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.62 and on latest stable 62.0.3202.75 but fixed on latest beta 63.0.3239.18 and latest canary 64.0.3251.0 using Windows 10, Ubuntu 14.04 and Mac 10.12.6. Hence Providing reverse bisect info.

Reverse Bisect Info:
================
Last Bad Build: 63.0.3225.0
First Good Build: 63.0.3226.0 

You are probably looking for a change made after 504560 (known good), but no later than 504561 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/a9ba55c8571ab0d2624c83d413ccc7215a185f51..9f0c480da9cb188c82e16e6c6751875a60a114cf

Probably fixed by : https://chromium-review.googlesource.com/684186

@rune:Could you please confirm if its safe to merge to M-62 in case we have stable refresh?

Unable to assign to @rune. Hence assigning to @treib: Please check the above issue.

Thanks!

Comment 3 by treib@chromium.org, Oct 30 2017

Owner: nainar@chromium.org

Comment 4 by nainar@chromium.org, Oct 30 2017

Labels: Update-Quarterly

Comment 5 by nainar@chromium.org, Oct 30 2017

Labels: -Update-Quarterly Update-Weekly

Comment 6 by nainar@chromium.org, Oct 30 2017

manoranjanr@, 

Can you perform a bisect looking at the change between 63 and 64 as we reverted the CL in question in 64? Just to make sure that I have a correct understanding of the bug. 
Cc: abdulsyed@chromium.org
nainar@, the bisect result in c#2 is indeed correct.

The re-land of below CL (https://chromium-review.googlesource.com/c/chromium/src/+/684186) has fixed this issue on M63 & M64. However we need to merge the same CL to M62 if it is really safe.

Thank you!

Comment 8 by nainar@chromium.org, Oct 30 2017

I am hesitant to merge this to 62, since I didn't write the original code. Would feel more comfortable keeping this in 63 only and letting the change move to stable with 63. 
Labels: M-63
If this is not blocking any critical user flow and nainar@ is hesistant to merge this to M62, my recommendation is to wait until M63 for the fix. 
Labels: -M-62 found-in-m62
Labels: -M-63 M-62
Per comment #6 & #7, this is already fixed in M63 but exists on M62.
Labels: -ReleaseBlock-Stable
Removing RB Stable
Status: Fixed (was: Assigned)

Sign in to add a comment