Steps to reproduce: 1. Enable WebRender. 2. Load https://perfht.ml/2mCyTQn 3. Wait for everything to stop loading and make sure there aren't any other animations happening in your browser window. 4. Move your mouse over the blue graphs in the top part of the page and move it around in a left-to-right alternating motion, for many seconds. Expected results: The vertical line should always follow the mouse and never pause. Actual results: After a few seconds, the page freezes. Usually it becomes unstuck after a few more seconds. If you move your mouse over the tabs in the UI, the page also becomes unstuck. I've noticed the same thing on Google Sheets where scrolling would appear to stop working.

Wait until everything has loaded. Move your mouse on the blue area from the left to the right, Then move it up in into the white area (or on "0.Xs" above it) and to the left. The grey vertical line freezes. You can't expand something from the tree on the bottom. Verify this by moving the mouse over the tab and trying it again. Sometimes I had to move my mouse over the tab at first to unfreeze the vertical grey line. mozregression --good 2017-11-03 --bad 2017-11-16 --pref "layers.acceleration.force-enabled:true" "gfx.webrender.enabled:true" "gfx.webrender.blob-images:true" > 14:59.23 INFO: Last good revision: e281e797c85d6c24961f504c6f27e364210bb0a7 > 14:59.23 INFO: First bad revision: 4cc53112a8d53d06d6831762aebac41fa2dcf744 > 14:59.23 INFO: Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e281e797c85d6c24961f504c6f27e364210bb0a7&tochange=4cc53112a8d53d06d6831762aebac41fa2dcf744 > 4cc53112a8d5 sotaro — Bug 1412249 - Fix DidComposite timing for EmptyTransaction r=nical Second test: mozregression --good 2017-11-14 --bad 2017-11-16 --pref "layers.acceleration.force-enabled:true" "gfx.webrender.enabled:true" "gfx.webrender.blob-images:true" > 7:56.66 INFO: Last good revision: e281e797c85d6c24961f504c6f27e364210bb0a7 > 7:56.66 INFO: First bad revision: 4cc53112a8d53d06d6831762aebac41fa2dcf744 > 7:56.66 INFO: Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e281e797c85d6c24961f504c6f27e364210bb0a7&tochange=4cc53112a8d53d06d6831762aebac41fa2dcf744 > 4cc53112a8d5 sotaro — Bug 1412249 - Fix DidComposite timing for EmptyTransaction r=nical

Thanks! Sotaro, can you take a look?

Thanks! I take a look.

I could reproduce the problem.

There were 2 problems about deciding sending DidComposite. WebRenderBridgeParent::RecvEmptyTransaction() sends back DidComposite if WebRenderBridgeParent does not have pending DidComposite requests. Its check was wrong. It check the pending request after adding current DidComposite request. WebRenderBridgeParent::FlushTransactionIdsForEpoch did not pop multiple pending TransactionIds.

attachment 8929385 [details] [diff] [review] addressed the problem for me.

(In reply to Sotaro Ikeda [:sotaro] from comment #5) > Created attachment 8929385 [details] [diff] [review] > patch - Fix worng decision of sending DidComposite. > WebRenderBridgeParent::FlushTransactionIdsForEpoch did not pop multiple > pending TransactionIds. WebRenderBridgeParent::FlushTransactionIdsForEpoch did not pop multiple pending TransactionIds that have same epoch.

Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c8cf6aa1633a Fix worng decision of sending DidComposite r=nical

I reproduced this bug following the steps from comment 0 and comment 1 on 59.0a1 (2017-11-16) under macOS 10.13. I retested it on the latest Nightly (2018-01-30) and 59.0b5 under macOs 10.13, Windows 10 x64 and Ubuntu 16.04 x64 using the prefs described in comment 2. The "gfx.webrender.blob-images:true" is no longer a boolean value, but an integer, so I tested this also, on an earlier beta build that contain the fix (58.0b5), when the pref in cause was still a boolean, just to make sure fix was successfully implemented. My concern is if the recently changed pref ("gfx.webrender.blob-images:true" is now integer) will affect this fix in any way. Any thoughts about this?

Since Bug 1425260 fix, pref "gfx.webrender.all" to true is a recommended way to enable WebRender. Could you check with it on latest version? Thanks.

I tested this issue based on the above comment, by setting the gfx.webrender.all on true and then retested by setting also the layers.acceleration.force-enabled on true . I obtained the following results: * macOS 10.13 - 59.0b6 - Not reproducible - 60.0a1 - I reproduced one time the crash filled in bug 1434630 (only after I set the gfx.webrender.all on true and also the layers.acceleration.force-enabled on true), but all the other attempts of verifying the issue on https://perfht.ml/2mCyTQn was successfully done, this is no longer reproducible. * Windows 10 x64 - 59.0b6 - Not reproducible - 60.0a1 - Not reproducible - Note: On older Nightly versions (e.g.2017-02-02) I encounter the crashes mentioned in bug 1435200 and bug 1433646 (only on one station - out of three I tested on). This is not the case anymore on the latest Nightly (2017-02-05). On the same station, everytime I close the Firefox Nightly window (while gfx.webrender.all is set on true), a popup is displayed with the error message ""Firefox Nightly has stopped working. A problem caused the program to stop working correctly"". Is this related and/or concerning? * Ubuntu 16.04 x32 - 59.0b6 - Not reproducible - 60.0a1 - Blocked by bug 1434961 * Ubuntu 16.04 x64 - 59.0b6 - The vertical line follows smoothly the mouse cursor, no delays or page freezing, but sometimes glitches are triggered, not only on this particular site (all the opened windows/tabs are affected) (only on one station - out of two I tested on) - see the screencast https://goo.gl/MEMcxA - 60.0a1 - The same issue as described on beta is applicable here, but the glitches are more noticeable. Should these above mentioned potential issues be assessed separately?

(In reply to Iulia Cristescu, QA [:JuliaC] from comment #13) > I tested this issue based on the above comment, by setting the > gfx.webrender.all on true and then retested by setting also the > layers.acceleration.force-enabled on true . I obtained the following results: > * macOS 10.13 > - 59.0b6 - Not reproducible > - 60.0a1 - I reproduced one time the crash filled in bug 1434630 (only > after I set the gfx.webrender.all on true and also the > layers.acceleration.force-enabled on true), but all the other attempts of > verifying the issue on https://perfht.ml/2mCyTQn was successfully done, this > is no longer reproducible. > * Windows 10 x64 > - 59.0b6 - Not reproducible > - 60.0a1 - Not reproducible > - Note: On older Nightly versions (e.g.2017-02-02) I encounter the crashes > mentioned in bug 1435200 and bug 1433646 (only on one station - out of three > I tested on). This is not the case anymore on the latest Nightly > (2017-02-05). Thanks for testing! It seems that the problem of this bug is addressed. > On the same station, everytime I close the Firefox Nightly window (while > gfx.webrender.all is set on true), a popup is displayed with the error > message ""Firefox Nightly has stopped working. A problem caused the program > to stop working correctly"". Is this related and/or concerning? Does the crash still happens with latest nightly? It seems like a different problem. Did you get a crash report of the crash? > * Ubuntu 16.04 x32 > - 59.0b6 - Not reproducible > - 60.0a1 - Blocked by bug 1434961 > * Ubuntu 16.04 x64 > - 59.0b6 - The vertical line follows smoothly the mouse cursor, no delays > or page freezing, but sometimes glitches are triggered, not only on this > particular site (all the opened windows/tabs are affected) (only on one > station - out of two I tested on) - see the screencast https://goo.gl/MEMcxA > - 60.0a1 - The same issue as described on beta is applicable here, but the > glitches are more noticeable. > Should these above mentioned potential issues be assessed separately? Yea, they needs to be assessed separately. They seems like different problems.

(In reply to Sotaro Ikeda [:sotaro] from comment #14) > > On the same station, everytime I close the Firefox Nightly window (while > > gfx.webrender.all is set on true), a popup is displayed with the error > > message ""Firefox Nightly has stopped working. A problem caused the program > > to stop working correctly"". Is this related and/or concerning? > > Does the crash still happens with latest nightly? It seems like a different > problem. Did you get a crash report of the crash? > There is no crash encountered here, but a error message instead (see the screenshot https://drive.google.com/file/d/1d0LZf49pQPOqQQaDH4bVmfVZV5Sq85OC/view?usp=sharing). When clicking on the "Close the program" button, nothing happens.

(In reply to Iulia Cristescu, QA [:JuliaC] from comment #15) > (In reply to Sotaro Ikeda [:sotaro] from comment #14) > There is no crash encountered here, but a error message instead (see the > screenshot > https://drive.google.com/file/d/1d0LZf49pQPOqQQaDH4bVmfVZV5Sq85OC/ > view?usp=sharing). When clicking on the "Close the program" button, nothing > happens. Thanks. I did not see the problem on my Win10 PCs. Can you crate a bug for it and paste about:support to there?

(In reply to Sotaro Ikeda [:sotaro] from comment #16) > (In reply to Iulia Cristescu, QA [:JuliaC] from comment #15) > > (In reply to Sotaro Ikeda [:sotaro] from comment #14) > > There is no crash encountered here, but a error message instead (see the > > screenshot > > https://drive.google.com/file/d/1d0LZf49pQPOqQQaDH4bVmfVZV5Sq85OC/ > > view?usp=sharing). When clicking on the "Close the program" button, nothing > > happens. > > Thanks. I did not see the problem on my Win10 PCs. Can you crate a bug for > it and paste about:support to there? Filed bug 1437442. Also, based om the previous comments and the fact that the above mentioned encountered issues are covered by other bugs, I will mark this as verified fixed.