Bisect:
432681 (good) - 432705 (bad)
https://chromium.googlesource.com/chromium/src/+log/da4e2467..70494244?pretty=fuller
Suspecting r432693 ( issue 658874 ) "Fix painting background for composited table cells in a non-composited row"
Committed in 56.0.2923.0
Merged to 55.0.2883.56

Thanks for the bisect. 

Suspected CL : https://chromium.googlesource.com/chromium/src/+/9c8fded973e0422c68dd85f3745b26a0a8d96085

Assigning to the Cl owner for further updates.

Tagging with current canary Milestone.

I can repro at ToT. It is likely due to my change. Will look further soon.

For reference there was a large table painting change (but specifically targeted at collapsed borders) in work for  http://crbug.com/663208 . That work is still planned to progress. Need to understand interaction if any between fix for this issue and that change.

Still happening, and would like to fix. Not sure how this stacks up against other regressions, but please take a look when you can (or re-assign).

Tried to reduce a test case from the codepen but copy-and-paste without other edits is not reproducing for some reason.

I would prefer to gate this bug on the work mentioned above in  crbug.com/663208  though that bug is currently marked a P3.

Deleted: 689479.html 3.8 KB

689479.html 3.8 KB View Download

Ah, codepen looks like it's using Sass to allow nested styles. Need to unwind that. http://sass-lang.com/

Reduced test case attached.

Deleted: test.html 649 bytes

test.html 649 bytes View Download

It looks like what's happening is something like:

- the table becomes composited during animation (a combo translate-opacity
  animation)
- we use LayoutTableCell::RowBackgroundDisplayItemClient as the client for
  painting throughout, and accordingly, m_layoutTableCell.row()->visualRect()
  varies throughout
- on the last frame painted, the table is de-composited, and the visual rect
  looks correct, but DrawingRecorder::useCachedDrawingIfPossible returns true,
  so we don't actually paint again. Thus even if we are using correct rect for
  paint invalidation, our paint commands have the wrong coordinates.

Visual rect detail at excerpted snapshots in chronological order:

TableCellPainter::paintContainerBackgroundBehindCell - before cache check [rect="0,2 14x20", client=0x0x2b30aeb45840: "RowBackground"].
TableCellPainter::paintContainerBackgroundBehindCell - before cache check [rect="218,10 14x20", client=0x0x2b30aeb45840: "RowBackground"].
TableCellPainter::paintContainerBackgroundBehindCell - before cache check [rect="16,10 14x20", client=0x0x2b30aeb45840: "RowBackground"].
TableCellPainter::paintContainerBackgroundBehindCell - before cache check [rect="400,10 14x20", client=0x0x2b30aeb45840: "RowBackground"].

LayoutTableCell::invalidateDisplayItemClients early-outs if !usesCompositedCellDisplayItemClients(). Thus when we first de-composite we are not invalidating the cell's RowBackgroundDisplayItemClient.

Two thoughts on possible solutions:

1. keep a bool on RBDIC to track the value of usesCompositedCellDisplayItemClients and make sure we invalidate RBDIC when the value flips.

2. change LayoutTableCell::backgroundDisplayItemClient to incorporate usesCompositedCellDisplayItemClients into its check for whether to return the RBDIC or the cell itself as the client. Essentially once the cell has an RBDIC then currently we use it thereafter, but arguably if we stop being composited we should stop using it. This will add some add'l conditional checks when retrieving the background display item client, but it's probably not too expensive.

It looks like #2 may be feasible, will look at preparing change.

https://codereview.chromium.org/2784673004/ is out for review.

Per code review feedback, conceptually given what we know now we could create a simple layout test case, but initial effort (attached) does not show issue.

In the test case I reduced above the final display item client invalidation for LayoutTableCell is due to bounds change but in this it's subtree. Suspect we need something that produces bounds change, but not subtree change, re: other involved code that runs for that frame. Decompositing a completed animation within a flex box does that, but I don't offhand know how else to produce that.

Prefer not to spend more time on this, plan to land test case in change at least for now.

Deleted: hack.html 431 bytes

hack.html 431 bytes View Download

Re #13: SGTM to land the current CL.

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

commit f8e03c0c5adc572d5e1f51e4093cecb0e661f05e
Author: wkorman <wkorman@chromium.org>
Date: Wed Mar 29 20:35:43 2017

Consider compositing state in row background display item client accessor.

BUG= 689479 

Review-Url: https://codereview.chromium.org/2784673004
Cr-Commit-Position: refs/heads/master@{#460524}

[add] https://crrev.com/f8e03c0c5adc572d5e1f51e4093cecb0e661f05e/third_party/WebKit/LayoutTests/compositing/flex-composited-animated-table-row-background-expected.html
[add] https://crrev.com/f8e03c0c5adc572d5e1f51e4093cecb0e661f05e/third_party/WebKit/LayoutTests/compositing/flex-composited-animated-table-row-background.html
[modify] https://crrev.com/f8e03c0c5adc572d5e1f51e4093cecb0e661f05e/third_party/WebKit/Source/core/layout/LayoutTableCell.h