1554861 - Part of the page is not rendered while resizing the window

Status: RESOLVED DUPLICATE of bug 1528180

(Core :: Graphics: WebRender, defect, P1)

Description

[Luke Usherwood]

Attachment: ResizingRenderingIssue.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I first noticed this with an internal website, but I found a public one that exhibits it:

https://trac.edgewall.org/ticket/10002

I simply resized the window larger in the down-right direction, and kept the mouse button down to create the screenshot.

FF 68-beta 4, with close to default preferences.
Windows 10-64bit
nVidia GTX-1060 w/ recent graphics drivers. (430.64)

Actual results:

Parts of the window do not render while resizing. (A bad clipping rectangle or something perhaps?)

Around the border areas where the page should render is just background colour.

However once the mouse is released, the window repaints correctly.

Expected results:

The complete window is rendered.

Comment 1

[Raluca Popovici, Desktop QA]

Hi, can you try turning WebRender Off in Firefox by switching the following preferences to False in case they are set to True by default:

gfx.webrender.all = False
gfx.webrender.all.qualified = False

and recheck if the issue still occurs.

I cannot reproduce this issue on my machine but I don't have nVidia GTX-1060 w.
If this issue is still reproducible on your machine, please let us know.

Comment 2

[Darkspirit]

(In reply to Raluca from comment #1)

gfx.webrender.all = False
gfx.webrender.all.qualified = False

(No, the second pref is even invisible.)
Please open about:config, set gfx.webrender.force-disabled to true and restart Firefox. If it doesn't fix the problem, please set it back to false.

You could also check if you have enabled privacy.resistFingerprinting. (bug 1507517)

Otherwise please open about:support, click on the "Copy text to clipboard" button, paste it into a text file and upload it here (Attach File). Thanks!

Comment 3

[Raluca Popovici, Desktop QA]

Hi Luke,

Can you please take a look at comment 2 and see if this issue still occurs.
If this bug is still reproducible even with this settings, please let us know.

Comment 4

[Luke Usherwood]

Hi, sorry for the delay. (It got lost in the noise over a busy work trip.)

Yes I can confirm that setting gfx.webrender.force-disabled = true avoids the issue.

Some more findings: It seems only about 50% reproducible and it seems only while the page is scrolled down, not at the top of the page. To reproduce, it may help to scroll down first, close and reopen the window (Ctrl+Shift+N). Then resize back and forth in diagonal directions a few times keeping the mouse button down. Sometimes it flickers a bit before the borders start "shrinking inwards" from the top or bottom.

privacy.resistFingerprinting is already set to false

Comment 5

[Darkspirit]

Attachment: 2019-06-17 11-27-59.mp4

(In reply to Luke Usherwood from comment #4)

Some more findings: It seems only about 50% reproducible and it seems only while the page is scrolled down, not at the top of the page. To reproduce, it may help to scroll down first, close and reopen the window (Ctrl+Shift+N). Then resize back and forth in diagonal directions a few times keeping the mouse button down. Sometimes it flickers a bit before the borders start "shrinking inwards" from the top or bottom.

Thanks! Confirmed with 68.0b10, Win10, GTX1060 at 80% zoom.

Comment 6

[Darkspirit]

Attachment: 2019-06-17 11-58-55.mp4

mozregression --launch 2019-06-16 --pref gfx.webrender.all:true -a https://trac.edgewall.org/ticket/10002
Scroll down.
Resize window to make it smaller.
Close cookie message.
Resize window to make it larger.
Bug occurs.

Does not happen without WebRender.

Comment 7

[Darkspirit]

mozregression --good 2019-01-10 --bad 2019-06-16 --pref gfx.webrender.all:true -a https://trac.edgewall.org/ticket/10002

11:30.15 INFO: Last good revision: f8b8346df03cfd7d683faf16ddded0afd528570b
11:30.15 INFO: First bad revision: 893f2ec05d7acf999174e200b042c3c9ef6fdd7c
11:30.15 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f8b8346df03cfd7d683faf16ddded0afd528570b&tochange=893f2ec05d7acf999174e200b042c3c9ef6fdd7c

893f2ec05d7acf999174e200b042c3c9ef6fdd7c Ryan Hunt — Bug 1519553 - Don't round scroll anchor adjustments to device pixels. r=dholbert

Comment 8

[Sotaro Ikeda [:sotaro]]

:rhunt, can you look into the bug by comment 7?

Comment 9

[Ryan Hunt [:rhunt] (on leave until early May)]

Attachment: Bug 1554861 - Disable clipping and scaling for top-level remote browsers to resolve regressions. r?mattwoodrow

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c4e6eca7339
Disable clipping and scaling for top-level remote browsers to resolve regressions. r=mattwoodrow

Comment 11

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/5c4e6eca7339

Comment 12

[Ryan Hunt [:rhunt] (on leave until early May)]

I don't believe this patch fixed the issue here. I got the wrong bug number, it was intended for bug 1560272.

Comment 13

[Ryan Hunt [:rhunt] (on leave until early May)]

My guess is that this is another place where scroll anchoring's subpixel behavior has a bad interaction with webrender.

Comment 14

[Jessie [:jbonisteel] pls NI]

I am trying to figure out if this is indeed a scroll anchoring issue or not. Kats, could it be an interaction with APZ?

Comment 15

[Kartikaya Gupta (email:[e-mail])]

I'm not able to reproduce this reliably enough to say. I can get it kind of intermittently but just from visual inspection I can't really tell what would cause it. If the regression range :darkspirit found is correct then it certainly would be a scroll anchoring issue.

Comment 16

[Darkspirit]

For me, it's easy and always reproducible with STR from comment 6. (Padlock > "Clear cookies & site data", then F5, to reproduce again.)
mozregression --launch 2019-07-09 --pref gfx.webrender.all:true layout.css.scroll-anchoring.enabled:true-a https://trac.edgewall.org/ticket/10002
mozregression --repo mozilla-inbound --launch 893f2ec05d7acf999174e200b042c3c9ef6fdd7c --pref gfx.webrender.all:true -a https://trac.edgewall.org/ticket/10002

But so far unable to reproduce with:
mozregression --launch 2019-07-09 --pref gfx.webrender.all:true layout.css.scroll-anchoring.enabled:false -a https://trac.edgewall.org/ticket/10002
mozregression --repo mozilla-inbound --launch f8b8346df03cfd7d683faf16ddded0afd528570b --pref gfx.webrender.all:true -a https://trac.edgewall.org/ticket/10002

Comment 17

[Emilio Cobos Álvarez (:emilio)]

I told Sean that I'd take a look at the scroll anchoring bits when I have some time.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

So I took a quick look, and I cannot reproduce this. However, what I can reproduce is bug 1519553, only if WebRender is enabled.

Can other people confirm that? I think we should fix that, and per the regression range this is likely to also fix this.

Comment 19

[Jessie [:jbonisteel] pls NI]

Can you still reproduce this?

Comment 20

[Darkspirit]

mozregression --find-fix --bad 2019-07-09 --good 2019-07-15 --pref gfx.webrender.all:true -a https://trac.edgewall.org/ticket/10002

21:38.13 INFO: First good revision: a37238f046d563fee862b36231ecbfd1ee18b0d8
21:38.13 INFO: Last bad revision: d35d90d0322baf6a93d2b8688bf1cdd5b9603474
21:38.13 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d35d90d0322baf6a93d2b8688bf1cdd5b9603474&tochange=a37238f046d563fee862b36231ecbfd1ee18b0d8

a37238f046d563fee862b36231ecbfd1ee18b0d8 Emilio Cobos Álvarez — Bug 1528180 - Don't align scroll offsets to layer pixels when using WebRender. r=tnikkel

This fixed the bug as seen in comment 0 and comment 6.
bug 1566178 was reproducible before and after the fix.