Go to https://codepen.io/thebabydino/pen/AzwKgy
Move mouse over the cat image

AR: Smooth transition to grey
ER: Jerky/non-smooth transition

Regression:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4db2640cb0cd60103ffa75fa76b11fa66257774f&tochange=5d03a9d6cb8aeba1bb488b989712ad9cfa0546d2

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Here's the testcase as a bugzilla attachment, for archival & simplicity.

In the regression range, this would probably be a regression from bug 1699890. This feels similar to bug 1760795, which was also flagged as a regression from that change (though the regression story there is a bit more complicated; see bug 1760795 comment 11).

Here's a testcase without external resources, and with the pseudo-element promoted to an actual element, and with the parent being larger so that you can see the transition background-color on the parent as well as its inherited value on the child.

It looks like we play the background-color transition smoothly on the parent element, but the inherited value on the child (in the upper left corner) only gets updated ~rarely, and that's what's causing the problem here.

EXPECTED RESULTS for testcase 2: the interior of the black-bordered area should all transition smoothly together.
ACTUAL RESULTS: the upper left quadrant (the child with inherited background-color) falls behind and only gets updated every second or so.

Chrome gives expected results.

With that testcase, this issue goes back to bug 1504065 as well; we have janky-looking "steps" for the animated background-color on the child, starting with that bug's patch. The thing that changed later (in comment 0's regression range) is that the final "snap" (at the end of the transition) takes much longer.

So: as with bug 1760795, this is a regression from bug 1504065 which got more noticeable with bug 1699890.

Here's a simpler testcase, simplified to remove all transparency. The bug still reproduces here just the same.

Here's that same testcase but with @keyframes so that no hovering is necessary.

:hiro, since you are the author of the regressor, bug 1699890, could you take a look?

For more information, please visit BugBot documentation.

For the inherited one in comment 7, it's not regressed by bug 1699890, it's been there (bug 1617328). I did double-check reverting bug 1699890 doesn't change the inherited case at all.

Keep NI to me, will take a look at the original case.

Okay, the original test case is a kind of results of combinations of bug 1699890 and bug 1617328. Before bug 1699890, we didn't run background animations starting off with transparent color (e.g. rgba(0, 0, 0, 0)) on the compositor thread. But after bug 1699890, we do run such kind of background animations on the compositor thread, thus we are able to see bug 1617328 unfortunately.

It is indeed a regression, but I am going to make this bug as a dup of bug 1617328. That means, the test case in comment 7 is quite valid for this bug. :)