Closed Bug 1554861 Opened 6 months ago Closed 4 months ago

Part of the page is not rendered while resizing the window

Categories

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

68 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1528180
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- disabled
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: ldubox-coding101, Assigned: emilio)

References

(Regression, )

Details

(Keywords: correctness, regression)

Attachments

(4 files)

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.

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.

Flags: needinfo?(ldubox-coding101)

(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!

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.

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

Flags: needinfo?(ldubox-coding101)
Component: Untriaged → Graphics: WebRender
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Attached video 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.

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Keywords: correctness
Attached video 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.

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

Has Regression Range: --- → yes
Flags: needinfo?(rhunt)
Keywords: regression
Regressed by: 1519553

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

Priority: -- → P1
Blocks: 1560272

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Flags: needinfo?(rhunt)
See Also: → 1528180
Target Milestone: mozilla69 → ---
See Also: → 1563717

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

Flags: needinfo?(kats)

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.

Flags: needinfo?(kats)

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

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

Flags: needinfo?(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.

Flags: needinfo?(emilio)
Depends on: 1565547

Can you still reproduce this?

Flags: needinfo?(jan)
See Also: → 1566178

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.

Status: REOPENED → RESOLVED
Closed: 5 months ago4 months ago
Depends on: 1528180
No longer depends on: 1565547
Flags: needinfo?(jan)
Resolution: --- → FIXED
Assignee: rhunt → emilio
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1528180
You need to log in before you can comment on or make changes to this bug.