Closed Bug 1830792 Opened 2 years ago Closed 2 years ago

Force DWM to update cached nonclient area

Categories

(Core :: Widget: Win32, defect, P2)

Unspecified
Windows 11
defect

Tracking

()

RESOLVED FIXED
114 Branch
Tracking Status
relnote-firefox --- 113+
firefox113 --- fixed
firefox114 --- fixed

People

(Reporter: rkraesig, Assigned: rkraesig)

References

Details

Attachments

(4 files)

On Windows 11, DWM sometimes doesn't update it's cached client area for a window if that window's client area, but not its size, changes. This can result in bug 1763981.

(This bug is separate from bug 1763981 only to avoid spamming users CC'd there with the metadata and administrivia resulting from patches here.)

This reverts Mercurial commit ec948153333a957e3ef5302b5b0f469eda0d48a8
(introduced as part of bug 1820066) due to reports of tearing while
playing full-screen video.

Remove unused code:

  • nsWindow::AutoErase() (allegedly overridable but nonvirtual function)
  • nsWindow::mIsPainting (flag which is never set)

... and perform a very minor comment emendation, for clarity.

Depends on D176841

This mitigation exposed bug 1763981. Unfortunately, not applying it on
Nightly made it look like bug 1763981 was fixed in Nightly, tricking
several users and developers and making testing needlessly more
difficult even after this was discovered.

Apply the mitigation across the board, regardless of release channel.
Developers may still set gfx.webrender.dcomp-apply-1704954 to override
this as needed for testing (e.g.) fixes for bug 1638709.

Depends on D176842

DWM doesn't update its cached nonclient region information when a window
changes its client area without changing its actual size.

This happens in Firefox when a maximized window becomes fullscreen. If
this happens, "flicker-resize" the window to force DWM to update.

Depends on D176843

Pushed by rkraesig@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ce5ed4bf2b1c [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r=sotaro https://hg.mozilla.org/integration/autoland/rev/0fa7665b8ede [2/4] Assorted minor nsWindow cleanup r=emilio https://hg.mozilla.org/integration/autoland/rev/dca34ff20fab [3/4] Remove is-nightly check for bug 1704954 mitigation r=gfx-reviewers,bradwerth https://hg.mozilla.org/integration/autoland/rev/7b723ef8f45e [4/4] Flicker-resize the window on first fullscreen entry r=emilio

Backed out for causing gtest failures regarding WebRenderNvidiaHighMixedRefreshRateNightly

Backout link

Push with failures

Failure log

Flags: needinfo?(rkraesig)

The failing gtest was testing for behavior that was deliberately removed in D176843. Removed and retested here; attempting reland.

Flags: needinfo?(rkraesig)
Pushed by rkraesig@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f98b225696bc [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r=sotaro https://hg.mozilla.org/integration/autoland/rev/de9223a8d783 [2/4] Assorted minor nsWindow cleanup r=emilio https://hg.mozilla.org/integration/autoland/rev/40bd3180e96c [3/4] Remove is-nightly check for bug 1704954 mitigation r=gfx-reviewers,bradwerth https://hg.mozilla.org/integration/autoland/rev/dd09461ffef5 [4/4] Flicker-resize the window on first fullscreen entry r=emilio

Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro

Beta/Release Uplift Approval Request

  • User impact if declined: Users who have DirectComposition disabled (e.g. due to the workaround of bug 1704954) may experience video tearing in fullscreen video on release of Fx113, as reported by one user here.

If so, this is probably worse than than the current fullscreen-clipping bug, which can be fixed merely by exiting and reentering fullscreen.

  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is not particularly risky, despite the very late state of the release cycle, because it merely reverts a default preference-setting (which is not even checked unless the user is already in fallback code) to what it was in Fx112 (the current release).

Note that the other commits in this patchset are riskier and should not be uplifted.

  • String changes made/needed:
  • Is Android affected?: No
Attachment #9331027 - Flags: approval-mozilla-beta?

Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro

Fx113 is in release, switching beta uplift request to release uplift request

Attachment #9331027 - Flags: approval-mozilla-beta? → approval-mozilla-release?

Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro

Approved for 113.0.1.

Attachment #9331027 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the 113.0.1 relnotes:

Fixed an issue which may cause users in some configurations to experience tearing when watching videos in fullscreen mode

I've tried to reproduce this using a couple of affected builds mentioned in Bug 1763981 (Firefox 99.0, 104.0.2) with Win 11 x64. It didn't reproduce on my laptop which had connected an external 2k monitor.

Brandon, Asidius, since you've encountered this in Bug 1763981, could you please verify the tearing issue when watching videos in fullscreen, and also if Firefox correctly enters into fullscreen mode on the following builds:

Flags: needinfo?(blues.krb)
Flags: needinfo?(ba001)

Apparently Bugzilla is preventing the needinfo?d users from responding here. I'm reopening the original bug for further commentary.

Flags: needinfo?(blues.krb)
Flags: needinfo?(ba001)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: