Issue 686426  has been merged into this issue.

Layout tree for the test case is:

layer at (0,0) size 800x90
  LayoutBlockFlow {HTML} at (0,0) size 800x90
    LayoutBlockFlow {BODY} at (8,8) size 784x74
      LayoutBlockFlow (anonymous) at (0,0) size 784x37
      LayoutBlockFlow (anonymous) at (0,37) size 784x0
        LayoutBlockFlow {DIV} at (0,0) size 784x0
      LayoutBlockFlow (anonymous) at (0,37) size 784x37
        LayoutText {#text} at (0,0) size 0x0
layer at (8,8) size 174x36 transparent
  LayoutInline {SPAN} at (0,0) size 174x36
    LayoutText {#text} at (0,0) size 174x36
      text run at (0,0) width 174: "fade line one"
layer at (8,45) size 176x36 transparent
  LayoutInline {SPAN} at (0,0) size 176x36
    LayoutText {#text} at (0,0) size 176x36
      text run at (0,0) width 176: "fade line two"

Need to consider further. A couple of brief notes:

There is support for a 'secondary id' in CompositorElementId, today used only by an enum, intended to allow differentiating element ids under the single 'primary id' (which is the one that's Element based). It would be weird to use the enum to store something like a monotonically increasing id to represent layers for a case like this. It would also be unfortunate to have to add a ternary id for this case. But doing so would be one way to address this need.

We could also disallow compositing animations in this case, but that's obviously undesirable. I'm not sure how common this is.

We could change Blink-side primary element id to be derived from the layout object itself in some manner, rather than from the DOM node associated with the element id.

Note I believe this has been the case for some time. Recent changes we've made toward SPv2 have changed behavior (line two fades in now, whereas on M56 line one fades in) but in both cases only one fades in, after which both snap into view.

Have not bisected back before M56. The recent change that likely affected ordering is https://codereview.chromium.org/2619383004 (preceded by https://codereview.chromium.org/2612093002).

Thanks for the report. This affects animation, but is it fair to say that the underlying questions are paint/SPv2 related?

I'm speculatively changing this to Blink>Paint, please change back if I'm wrong.

Was this fixed recently? I recall a review going by about id mappings.

Still happens on trunk.

Not fixed, and potentially related to  http://crbug.com/683774 .

This was possibly introduced by https://codereview.chromium.org/1973083002 ~8mos ago but I still haven't bisected back to before then to check. But we used to manage composited animations by layer id, and the shift to element id could have broken that.

I will pick this up since I am also owner of the other bug. Have been discussing this with pdr@ in person.

From discussion today, there is an updated plan re: c#2 wherein we expect to move Blink element ids to be based on fragments in some manner. Since even basing on layout object is insufficient as a single composited object could be fragmented into multiple fragments, each needing to be animated separately.

Output of discussion around work for  issue 718564 .

Perhaps chrishtr@ should take this as he is working on related element id logic and has done the recent fragment work. Unassigning self.

ClusterFuzz testcase 6616851519111168 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I don't know what ClusterFuzz is smoking...

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Should this be closed after all the work on ElementId?

Yes, thanks.

This still repros.