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

Issue 599359 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

CSS counter-increment: not work correctly when dynamic change attribute of the element

Reported by isayev.i...@gmail.com, Mar 31 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Example URL:
https://jsfiddle.net/nzv4ps8u/7/

Steps to reproduce the problem:
1. Visit link https://jsfiddle.net/nzv4ps8u/7/
2. Notice the ninth element of list named "Two-Problem-element"  has number "2"
3. Notice the eighth element named "One-Problem-element"  has number "1"
4. Press the button (it toggles a CSS attribute). The ninth element has number "0", but must have "1"
5. Press the button again (it CSS attribute changes back). The ninth element (as well as eighth) has number "1", but must have "2". The eighth element must have "1"

What is the expected behavior?
When we press the button first time the ninth element of the list should have a number "1", but have "0"

When we press the button second time the CSS classes are back in the original state, and I would expect the UI to be back in the same state as well – the eighth element must have number "1", the ninth element must have number "2"

What went wrong?
It seems that the counter doesn't count properly, but I don't now when and why

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 49.0.2623.87  Channel: n/a
OS Version: OS X 10.11.3
Flash Version:
 
Components: Blink>CSS
Status: Untriaged (was: Unconfirmed)
I reproduce the described behavior on the linked page. Whether that behavior is expected or not is far outside my understanding of CSS. Tagging this Blink>CSS for triage.
Cc: ramy...@samsung.com
Labels: -OS-Mac Needs-Bisect OS-All
May be related to  issue 591267 


Labels: -Needs-Bisect M-51
Able to reproduce the issue on Win 7, Ubuntu 14.04 and Mac 10.11.4 using latest stable 50.0.2661.75,49.0.2623.112(previous stable) and canary 52.0.2707.2.
This is a non-regression issue since 30.0.1549.0, as the 1st scenario does not work though the Scenario-2 does work in M 30 and it does not work in 34.0.1757.0,the latest stable, canary.
Scenario-1 : When we press the button first time the ninth element of the list should have a number "1", but have "0"

Marking this Untriaged assuming its a non-regression issue.

Note : Its working fine on FireFox 45.0.1.

Comment 4 by meade@chromium.org, Apr 15 2016

Cc: nainar@chromium.org
Labels: -Type-Compat Hotlist-Interop Type-Bug
Status: Available (was: Untriaged)
I'm not sure if this is the same as  issue 591267 , so I'm leaving them both open. The fix is probably somewhere in the same code though.

Comment 5 by nainar@chromium.org, Feb 13 2017

Labels: Update-Quarterly

Comment 6 by shend@chromium.org, Oct 31 2017

Labels: ApproachableBug
Should be approachable, but could be a bug in Blink>Layout.
Labels: -Update-Quarterly
Project Member

Comment 8 by bugdroid1@chromium.org, Dec 12 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03c0c40d9fd01a01d3ea7992fa3779a876a3740e

commit 03c0c40d9fd01a01d3ea7992fa3779a876a3740e
Author: Darren Shen <shend@chromium.org>
Date: Tue Dec 12 04:21:51 2017

[css-counters] Update counters correctly under counter-reset changes.

Currently we are not updating counter values correctly when we change
or add counter-resets. For example, if we have something like:

<div style="counter-reset: c">
  <p style="counter-increment: c">First</p>
  <p style="counter-increment: c">Second</p>
</div>

we would construct the following counter tree (approximately):

reset
  increment // first
  increment // second

When we insert a new reset node after the first item, we would get
something like:

reset
  increment // first
  increment // second
reset

The correct behaviour would be to move every (non-reset) counter
node after the first node to be a child of the new node:

reset
  increment // first
reset
  increment // second

Bug:  463513 ,  599359 ,  591267 
Change-Id: I28cbf3c13c86336ad3f6f44bf865c59d9f82d98a
Reviewed-on: https://chromium-review.googlesource.com/809984
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523333}
[add] https://crrev.com/03c0c40d9fd01a01d3ea7992fa3779a876a3740e/third_party/WebKit/LayoutTests/fast/css/counters/update-reset-counter-parent-sibling.html
[add] https://crrev.com/03c0c40d9fd01a01d3ea7992fa3779a876a3740e/third_party/WebKit/LayoutTests/fast/css/counters/update-reset-counter-sibling.html
[modify] https://crrev.com/03c0c40d9fd01a01d3ea7992fa3779a876a3740e/third_party/WebKit/Source/core/layout/CounterNode.cpp
[modify] https://crrev.com/03c0c40d9fd01a01d3ea7992fa3779a876a3740e/third_party/WebKit/Source/core/layout/CounterNode.h
[modify] https://crrev.com/03c0c40d9fd01a01d3ea7992fa3779a876a3740e/third_party/WebKit/Source/core/layout/LayoutCounter.cpp

Comment 9 by shend@chromium.org, Dec 12 2017

Components: -Blink>CSS Blink>Layout
Owner: shend@chromium.org
Status: Fixed (was: Available)

Sign in to add a comment