Steps to reproduce: 1. Open https://perfht.ml/2wt521E and wait for it to load completely. 2. Move your mouse over one of the tree rows. 3. Make sure everything has settled and nothing in the browser is painting. 4. Move your mouse over a different tree row. Expected results: The arrow button at the end of the hovered tree row should appear immediately. Actual results: It takes about half a second until the arrows shows up. Similar things can be seen when pressing Ctrl+Shift+1 to start/stop the profiler: While perf-html.io is on the screen, and nothing else is causing paints, the button highlight doesn't update when the profiler state changes, or it updates to show the previous state that you just left, as if it was painting the previous paint.

It might be similar to Bug 1460432.

Yeah it sounds like bug 1460432. I'll look into it.

mozregression --good 6f52281bccaa9f7624ec5bfac9e85e41f1928547 --bad 7c83ceac4be6d055bebd870a82b78b76de14b9d7 --pref gfx.webrender.all:true startup.homepage_welcome_url:'https://perfht.ml/2wt521E' > 8:03.79 INFO: Last good revision: 9554a93583058c35d86878d398d7d4688a3eb86f > 8:03.79 INFO: First bad revision: 25652d08b28edca783e238dcce7bbad52fc545e1 > 8:03.79 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9554a93583058c35d86878d398d7d4688a3eb86f&tochange=25652d08b28edca783e238dcce7bbad52fc545e1 > 25652d08b28e Kartikaya Gupta — Bug 1459686 - Include async image updates in the displaylist transaction. r=sotaro > b27eadf1b8de Kartikaya Gupta — Bug 1459686 - Refactor to have the ApplyAsyncImages callsite provide the transaction. r=sotaro > 4869243efd9c ffxbld — Bug 1459686 - Remove WebRenderCommandBuilder::mParentCommands which is always empty. r=sotaro

This is a result of the second patch from bug 1459686. In that patch, CompositeToTarget ends up sending a transaction and then reusing the TransactionBuilder. But the async-scene-build flag doesn't get set on the new transaction properly. i.e. when we create the TransactionBuilder for the first time, it correctly sets the flag based on [1]. But after sending the transaction the new transaction is created and swapped in at [2] without setting the flag. [1] https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/gfx/webrender_bindings/src/bindings.rs#986-993 [2] https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/gfx/webrender_bindings/src/bindings.rs#1298

The patches on bug 1457466 should actually fix this, but would leave this footgun-ny behaviour in place. So I'll fix it here.

I was able to repro this more easily than bug 1460432 so the STR on this bug are what I used to test. Inverting dependency relationship; I'll put the patch here and we can see if it fixes bug 1460432 as well.

Comment on attachment 8974799 [details] Bug 1460495 - When sending a transaction, ensure the new transaction that takes its place has the same async-scene-build flag set. https://reviewboard.mozilla.org/r/243188/#review249062 Looks good.

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4e38ca9aaa48 When sending a transaction, ensure the new transaction that takes its place has the same async-scene-build flag set. r=sotaro