Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/ffb5de3934abd4e16399b2f79e7100823c6076fd (Don't propagate cmdline flags that are not read by renderer processes.).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

shend@, could you PTAL?  The failing DCHECK was introduced in r523333

I am adding Test-Predator-Wrong-CLs label and removing myself as an owner, because I think the explanation from  https://crbug.com/823148#c3  applies here as well.

Hi kojii-san, it looks like our assumption in [1] are wrong. The test case is large and flaky, so I can't figure out why our assumptions are failing.

Currently we terminate as soon as we hit the first non reset node. A possible fix might be to continue the loop and do this for all the non reset nodes? I don't remember this code much anymore so I have no idea if this is okay. WDYT?

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/CounterNode.cpp?l=378

Sounds good, thank you!

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

commit ecc13498a3f28de8c38b1555a8f2d786b98c1b38
Author: Darren Shen <shend@chromium.org>
Date: Tue Mar 27 05:55:38 2018

[css-counters] Fix DCHECK failure in counter node manipulation.

We are failing a DCHECK where we assumed that reset nodes cannot have
non-reset nodes as their next sibling (i.e. a reset node cannot be
followed by a non-reset node on the same level). We were using this
assumption when we wanted to reparent all non-reset nodes and we stopped
at the first reset node.

However, this assumption seems to be wrong as we are hitting this DCHECK
on ClusterFuzz. This patch speculatively fixes this issue by not
stopping at the first reset node.

This is a speculative fix.

Bug:  822217 
Change-Id: I83679c51d82d28c7bd1ace92b27cc7910b9c9db4
Reviewed-on: https://chromium-review.googlesource.com/981334
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546035}
[modify] https://crrev.com/ecc13498a3f28de8c38b1555a8f2d786b98c1b38/third_party/WebKit/Source/core/layout/CounterNode.cpp

Test is flaky so ClusterFuzz can't automatically close the issue. Manually marking this issue as Fixed since the DCHECK has been removed.