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

Steps to reproduce:

• Run a fresh copy with a new profile of Firefox developer edition 86.0b5 (64-bit) on Windows 7.
• Change Hardware acceleration to off (uncheck "Use hardware acceleration when available")
• Restart FF
• Open another window (menu File - new window).
• Try to drag one window on another or into the border of the screen or changing active window with Alt-tab.

Actual results:

Some areas don't refresh, so they contain a dirty image of the previous window or some other stuff.

Expected results:

Expected the correct invalidation regardless of the desktop changes scenarios.
When the hardware acceleration is on, the issue is not present
Also I was at the firefox developer edition channel for a long time and I noticed this just a couple weeks ago, so probably some regression bug from a very recent changes

I assume the HW acceleration is enabled by default for you, is it?
Marking as S3 in the meantime. Maybe Jeff knows what to do with it.

Max are you able to find a regression window using mozregression?

HW was off for me for some historical reasons, probably for the https://bugzilla.mozilla.org/show_bug.cgi?id=812771 reported by myself. Though the previous issue is not marked solved, maybe some other changes finally will allow to return HW back.
I also tried to reproduce issue 1690759 with FF 86.0b6 on Windows 10 with no luck (or very little luck not worth mentioning due to obscure nature). So probably the incomplete redraw can be related to the Windows 7 only or an older DirectX version.
I will try to apply mozregression method to my findings and report it back.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

Max are you able to find a regression window using mozregression?

I made the bisects on another computer with Windows 7. I mention this to note that the issue was not specific to a particular station.

I should also correct my first assumption about possible unconditional non-redrawing invalidated areas. It is more about delaying drawing for a long period, in my tests, about 5-12 seconds. I'm not sure, but on the first computer the delay might be even longer so I probably failed to wait enough for this be be noticed. Also this later observation is the reason why my first bisect was not successful, sometimes I saw a 2-seconds delay redrawing and marked such tests with a good verdict.

The second bisect was more successfull.
The final info from mozregression GUI log is
Bug 1684170 - Decouple WebRender and Software WebRender gfxConfig features. r=jrmuizel
......
Lack of support of (hardware) WebRender should not block Software
WebRender support. This can happen when ANGLE isn't supported, for
example.
.......
Differential Revision: https://phabricator.services.mozilla.com/D100445

Great, bug 1684170 makes sense. That likely enabled software webrender in your configuration. You should be able to confirm that by setting gfx.webrender.force-disabled=true, restarting and checking that about:support has "Basic" instead of "WebRender (Software)" in the "Compositor:" section.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)

Great, bug 1684170 makes sense. That likely enabled software webrender in your configuration. You should be able to confirm that by setting gfx.webrender.force-disabled=true, restarting and checking that about:support has "Basic" instead of "WebRender (Software)" in the "Compositor:" section.

That's correct, I see "Basic" in Compositing after changing this setting (the value was false before my change)

Additional information about whether it is a delay in redrawing or total ignoring. At the computer1 I met a non redrawn area and waited patiently for about 60 seconds, no redraw occurred. I'm not sure, but it was probably a static (after loading) page that don't force any dynamic changes to the content.

Today Firefox updated to 86.0b7 and I see no symptoms of the. issue. The properties mentioned above are now in the following states:

• Use hardware acceleration when available: unchecked
• Compositing: Basic
• gfx.webrender.force-disabled: false (non- bold)

Has some other change also fixed this issue?

Probably the issue has a on-going process, just to report the changes on my side.

I see again the symptoms of late or absent redrawing in FF 87.0b2

• Use hardware acceleration when available: unchecked
• Compositing: WebRender (Software)
• gfx.webrender.force-disabled: false (bold)

I didn't change myself anything in this browser during all this time, so the Compositing and boldness changes probably come from the updates.

Max, I believe this is a duplicate of bug 1690216, which was fixed and uplifted to 87.0b5. Can you check with a later beta if redrawing problem still occurs in Software WebRender on 87.0b5 or later beta?

Lee, with the current settings and status of my browser (87.0b8 (64-bit), Compositing: WebRender (Software), gfx.webrender.force-disabled: false (non-bold)) everything seems to look fine, but should I also test it with other combinations of webrenderer related settings? For example, the web search reveals also gfx.webrender.all and gfx.webrender.software to affect final Compositing value.

So long as it said "WebRender (Software)", that is what I needed to know and should confirm that bug 1690216 fixed this.

Ok, some correction on my side probably not affecting the overall resume of the issue. I made a sensitive error by pasting a different string in my last message here. Actually Compositing was Basic in my primary today test, but after noticing the mistake some hours later I forced it to be Software by making gfx.webrender.all and gfx.webrender.software true and the second test also worked flawlessly.