unexpected rendering of sibling elements of a element being removed
Reported by
tsk....@gmail.com,
Dec 15 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: There is a small sample of this issue. It may be easier to understand than my description below. http://codepen.io/TasukuUno/pen/aBQmzL 1. In css you use general sibling selector (E ~ F) of a element which will be removed by user action. 2. When an element is removed and its className is removed of it at the same time, the general sibling elements are still rendered in the previous style. What is the expected behavior? If an element is removed and/or its className is removed, the general sibling elements should not be rendered in E ~ F style. What went wrong? see attached file Did this work before? Yes chrome 51.0.2704.84 Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 24.0 r0 environment: - OS X El Capitan reproduced browsers: - Google Chrome 53.0.2785.116 - Google Chrome 54.0.2840.71 - Google Chrome 55.0.2883.95 non reproduced browsers: - Firefox 50.0 - Firefox 50.1.0 - Safari 9.1 (11601.5.17.1)
,
Dec 15 2016
,
Dec 15 2016
Able to reproduce this issue on Windows 10, Ubuntu 14.04 and mac 10.11.6 with chrome version M55-55.0.2883.95. Issue is broken in M53 Bisect Info: =========== Good build : 53.0.2782.0, Revision Range -402386 Bad build : 53.0.2784.0, Revision Range -403038 After executing the per-revision-bisect script in reverse, i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/07a50f9a656f418b9ec2070fcc015cfd36cb9c3b..6e099723055362705266d6d4c70d4fdaa4c071c6 The suspecting Change Log is : ----------- https://chromium.googlesource.com/chromium/src/+/1f82047b13f02be39b8104b6afda0615e60a7cee From the above CL suspecting the below change --------------------------- Review-Url: https://codereview.chromium.org/2089063005 rune@- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner.
,
Dec 15 2016
,
Dec 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/aa0b505f520f9d14f7f90048e4a256dd408da849 commit aa0b505f520f9d14f7f90048e4a256dd408da849 Author: rune <rune@opera.com> Date: Fri Dec 23 07:51:25 2016 Reschedule sibling invalidations as descendant on removal. When removing elements we schedule sibling invalidations based on element attributes and state as descendant invalidations when necessary. However, that didn't work correctly if we removed an attribute and then removed the element before the sibling invalidation for the attribute was effectuated. For instance, if you remove a class affecting succeeding siblings through selectors, we schedule an invalidation set for that change, but it will be cleared right after if we remove the element (see the added test). Instead we reschedule sibling invalidations on the parent node before the invalidations for the removed element are cleared. R=esprehn@chromium.org BUG= 674326 Review-Url: https://codereview.chromium.org/2592423002 Cr-Commit-Position: refs/heads/master@{#440598} [add] https://crrev.com/aa0b505f520f9d14f7f90048e4a256dd408da849/third_party/WebKit/LayoutTests/fast/css/invalidation/reschedule-for-removed-sibling.html [modify] https://crrev.com/aa0b505f520f9d14f7f90048e4a256dd408da849/third_party/WebKit/Source/core/css/invalidation/StyleInvalidator.cpp [modify] https://crrev.com/aa0b505f520f9d14f7f90048e4a256dd408da849/third_party/WebKit/Source/core/css/invalidation/StyleInvalidator.h [modify] https://crrev.com/aa0b505f520f9d14f7f90048e4a256dd408da849/third_party/WebKit/Source/core/dom/Document.cpp [modify] https://crrev.com/aa0b505f520f9d14f7f90048e4a256dd408da849/third_party/WebKit/Source/core/dom/StyleEngine.h
,
Jan 2 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Dec 15 2016