Affected versions

• Firefox 68.0a1 (20190409221047)

Affected platforms

• Windows 10 x64
• Ubuntu 18.04 x64

[Prerequisites]:

• Ensure that in about:support at Graphics section “Compositing” has the “WebRender” attribute, if not set gfx.webrender.all to true.
• Possible Nvidia GPU needed for enabling WebRender.

Steps to reproduce

1. Open Firefox and open at least 4 tabs.
2. Continuously drag the browser from the bottom area to resize it and move the mouse up and down.
3. Observe the tabs section.

Expected result

• Browser is resized properly and no visual glitches are displayed.

Actual result

• Visual glitches appear on tab section from the browser.

Regression range

• Last good revision: 3b08a133c893b960f15e014a8f36c954d31fda34 (2019-03-01)
• First bad revision: 997e98493dbcd55c95b4a6eb4a44f563cd6174e9 (2019-03-02)
• Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3b08a133c893b960f15e014a8f36c954d31fda34&tochange=997e98493dbcd55c95b4a6eb4a44f563cd6174e9

Additional Notes

• The issue is reproducible with only one tab opened but it’s more visible with more tabs.
• I could not reproduce the issue on 66.0.3 (20190409155332) or 67.0b9 (20190408123043) even if I set gfx.webrender.all to true.
• The issue is not reproducible on macOS 10.12 on latest Nightly with gfx.webrender.all set to true.
• On my machine (GPU- Intel(R) HD Graphics 630) Nightly starts as default with Compositing to WebRender and setting layers.acceleration.disabled to true removes the issue and changes Compositing to Basic.
• Attached a screen recording with the issue.

This is pretty annoying when resizing the window on Windows, so might be worth being high priority.

This is a regression caused by bug 1531217, but I believe Dzmitry is on PTO currently?

Going to find someone to take a closer look at this today so we can determine urgency around fixing.

My findings so far:

• I initially tried to revert the regressing patch. Unfortunately there are a large number of conflicts that are non-trivial to resolve.

• After some debugging, I am fairly confident I can see the issue. The patch changes the target rect of the main frame buffer to be calculated during frame building time, rather than at render time. This doesn't work correctly during resizing, since the window size can change (a) between the frame build and the render occurring and (b) when re-rendering the same frame.

• I tried to add a workaround / hack for the problem above. I think it improves it, however I was still seeing similar glitches during resizing. I then found out that these glitches occur on Linux even with WR disabled, and even before this patch landed, as long as GL layers are enabled. So it seems that there are two similar issues here (1) an existing issue on Linux + GL layers when resizing, and (2) the issues caused by this patch mentioned above. This makes it difficult to confirm if my workaround is helping.

Next steps:

• Update my Windows dev environment and attempt to reproduce on there.

I have a couple of questions on priority of this bug:
(a) Are we confident it doesn't occur on the current 67 beta on Windows? If so, the priority is probably less urgent?
(b) What date do we think we must have a fix for this by?

I tested locally on a Windows + nVidia machine. It seems to occur in both beta (67) and nightly (68) from what I can tell. It seems worse in the nightly, but I can definitely see resizing glitches in the 67 beta on Windows when WR is enabled. It'd be good if someone else could confirm that they see the same though.

Hello, I can confirm the issue is reproducible on 67.0b11 (20190415085659) with WebRender on. Attached a screen recording on 67.0b11 with the issue. I didn’t notice that on the first place because it’s not reproducing on about:config page, but changing on a content loaded tab activates the glitch. I am sorry for misleading here. I can’t reproduce it on 66.0.3 (20190409155332) with WebRender on tho.

No worries, thanks for the confirmation! That matches what I'm seeing, and the regression commit above landed after 66, so this also makes sense. I'll continue investigating on a Windows machine tomorrow.

This is a hack / workaround that seems to fix the resizing bug on Windows, and make it much better on Linux. It'd be great if we could get some testing on this to see if it causes any other issues (I'll be testing more with it locally today).

Comment from the code change:

This is a hack / workaround for a resizing glitch. What happens is that the framebuffer rect / content origin are determined during frame building, rather than at render time (which is what used to happen). This means that the framebuffer rect/origin can be wrong by the time a frame is drawn, if resizing is occurring. This hack just makes the framebuffer rect/origin be hard coded to the current framebuffer size at render time. It seems like this probably breaks some assumptions elsewhere, but it seems to fix the bug and I haven't noticed any other issues so far. We will need to investigate this further and make a "proper" fix.

Pending try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f31ad6dd51a6aedaecaf31a3d46311b0d1ee762

The try run looks good, and I haven't seen any issues in local testing so far.

I spent a bit of time today also testing the try build on Windows 10 (Intel GPU) and it looks good. It seems to resolve the glitching and I haven't seen any other weird behaviour or regressions.

https://hg.mozilla.org/mozilla-central/rev/b03a3303ad6e

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

(In reply to Pascal Chevrel:pascalc from comment #13)

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

So far it only caused a regression on an experimental and still disabled by default feature which won't be uplifted to 67.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #14)

(In reply to Pascal Chevrel:pascalc from comment #13)

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

So far it only caused a regression on an experimental and still disabled by default feature which won't be uplifted to 67.

Given that this is a disabled by default feature, let's mark it back as affected and see if an uplift is desirable.

An uplift for this is definitely desired - I was going to let it sit in nightly over the long weekend and request uplift on Monday if it doesn't break anything else.

Comment on attachment 9059121 [details]
Bug 1543356 - Visual glitches on resizing the browser with WebRender.

Beta/Release Uplift Approval Request

• User impact if declined: Very noticeable rendering glitches during window resizing.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Ensure WebRender is enabled, and confirm that resizing the window does not show any glitches similar to the screen recording in the bug.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk since (a) only affects users enrolled in WebRender on nVidia desktop + Win10, (b) Has been tested in nightly for a few days, (c) Is a small / simple patch that's easy to back out. The alternative is to ship with visual glitches during resizing for WebRender users.
• String changes made/needed:

Hi, This issue is verified as fixed in our latest nightly build 68.0a1 (2019-04-21).

Comment on attachment 9059121 [details]
Bug 1543356 - Visual glitches on resizing the browser with WebRender.

Fixes visual glitches when resizing windows for users opted into WebRender trials. No impact on users who aren't. Approved for 67.0b13.

https://hg.mozilla.org/releases/mozilla-beta/rev/50707a995cd5

Dzmitry, when you are back from PTO, could you investigate what the right fix for this is (to fix the visual glitch without regressing doc splitting)? Feel free to ping me on IRC for more context.

Hi, I retested this issue In Firefox Beta 67.0b13 and the issue no longer occurs. I will mark this issue accordingly.

Should we leave the QeVerify+ flag just in case more modifications are made and this needs to be retested on both Nightly and Beta ?

Created bug 1546371 to follow-up

Hi, I'm moving the QeVerify+ bug to the Follow up bug so we can keep track of it.

Hi Jessie,

We could reproduce this issue on latest Beta 71.0b9 on Laptop with Nvidia card (force enbled webrender). If WebRender is disabled, the issue is not reproducible.

Should we submit a new issue or re-open this one?

Note: The issue is not reproducible on Desktop with Nvidia, Intel or AMD cards.

Let's re-open

Just to be sure, we are 100% sure this is not reproducible on desktop, and only laptop? Can it be reproduced on Intel or AMD laptop or just Nvidia?

Would it be possible to get a screen recording of the issue you're seeing on laptop? This may help to identify whether it's related to the fix above, or something else entirely?

(In reply to Jessie [:jbonisteel] plz needinfo from comment #28)

Just to be sure, we are 100% sure this is not reproducible on desktop, and only laptop? Can it be reproduced on Intel or AMD laptop or just Nvidia?

On desktops, this issue is not reproducible.
Also, I tested on a laptop with Intel HG Graphics 5500 (force enbled webrender) and the issue is not reproducible. For now, it seems to be reproducible only on laptop with Nvidia card (force enbled webrender).

NI-ing Glenn to take another look

Alexis, can you see if you can reproduce this?

I tried to repro this on an old laptop with an nVidia Quadro GPU, but it didn't seem any different than resizing on a desktop with nvidia GPU. It wasn't obviously wrong to me. Maybe it's GPU specific? I wonder if it might only occur on machines with a dual GPU where the nVidia GPU is drawing and the Intel GPU is presenting?

Also having trouble reproducing this. Are you also seeing this on nightly, or just beta?

whoop there we go, definitely happens on beta, but not nightly! (for me)

Ok no now I'm confusing myself (mozregression-gui makes it weirdly hard to actually get a proper beta build). I found buggy behaviour similar to that originally described in the original post on beta 70 not 71. On 71.0b11-beta and 72.0a1-nightly I can't see the different behaviour described in the reopening comment (tabs look fine but sometimes the page's content gets messed up way beyond the scope of the the invalidated region).

For the messed up tabs, I specifically ran across this range in mozregression:

• first bad (2019/08/26): https://phabricator.services.mozilla.com/D42406
• fixed (2019/09/08): https://phabricator.services.mozilla.com/D45143 (Bug 1578330, landed in 71 nightly, uplifted to 70 beta)

Helpful to have:

• Your about:support information on the setup where this happens
• Whether you see this at all on nightly
  • If you don't: a mozregression range identifying when this was fixed might be desirable

Hi Alexis, Here is the About:support information from that device, the issue occurs in Nightly as well.

Anything interesting in about:support?

All that stands out is that they have another Turing card (Nvidia's newest architecture, the same one the troublesome 2080 is from). Sadly, the 2080 we borrowed doesn't seem to show the problem.

Unassigning since I can't repro here on the hardware I have available. Not sure who this should go to, Jessie?

Brindusa, it feels like there's a bunch of confusion on this bug. Can you open a new issue for the problem that only happens on the Nvidia laptop?

I have opened a new issue as requested please see Bug 1601204