Steps to reproduce

1. Click the "Show Desktop" button on the right of the Windows taskbar to minimize all Windows.
2. Click the same button again to open them again.

Actual result

a) The Firefox UI (search/menu bar, tabs) was frozen
b) The loaded website stopped responding to inputs, but videos continue to play (audio only) and the website can still be scrolled (but it will be blank after about 1 screen of scrolling)
c) The close tab and close window buttons continue to work

Expected result

The browser should have continued to work as normal.

Other information

• This bug occurs on Firefox Developer Edition (v 107.0b5 build 20221025185841) but not on Firefox 106.0.1
• This does not only happen after minimizing the browser using Show Desktop, but that is the most reproducible way
• This does not happen when minimizing the browser using the button on the top right of the browser window.
• This problem can be reproduced in a new profile
• The following has been tried, but does not help: accessibility.force_disabled = 1; disabling hardware acceleration in settings
• I've tried to search through the existing bug reports but haven't found any current ones that match my issue.
• about:support printout https://hastebin.com/ibeyazecow.yaml

~jhkmnl

[Tracking Requested - why for this release]: UI stops responding.

I can reproduce this in Firefox107.0b4 and nightly108.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c2224b54c6724524328e6448be8e96f64414c5c6&tochange=1c24a2ccce19cd7febaa198670c399527092d60b

Set release status flags based on info from the regressing bug 1789823

:emilio, since you are the author of the regressor, bug 1789823, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

The bug is marked as tracked for firefox107 (beta). However, the bug still isn't assigned.

:hsinyi, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

If we get via OnFrameChanging, we compute a new sizemode, but never store it on
the widget, yet we notify that it has changed.

We were relying on a call to mWindow->SetSizeMode from the widget delegate
which I removed in:

https://hg.mozilla.org/integration/autoland/rev/c9785cd100fcea9e82623457efb09b54619053be

Instead, call EnsureSizeMode to make sure we already have the right sizemode
when notifying our listener.

Back out regressing patch on windows only. This is safer to uplift.

Comment on attachment 9300342 [details]
Bug 1797463 - Patch for beta.

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Backs out the regressing patch (which was a one-line removal) only on windows
• String changes made/needed: none
• Is Android affected?: No

Backed out changeset cf1b318a7a98 (Bug 1797463) for causing mochitest failures on test_sizemode_events.xhtml.
Backout link
Push with failures <--> c3 <--> bc2
c3 Failure Log
bc2 Failure Log

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

I managed to reproduce this issue on a 2022-10-24 Nightly build on Windows 11 using the STR from the Description. Verified as fixed on Nightly 108.0a1(buildID: 20221027095047) on Windows 11 and Windows 10.

Comment on attachment 9300342 [details]
Bug 1797463 - Patch for beta.

Approved for 107.0b6.

https://hg.mozilla.org/releases/mozilla-beta/rev/2f6e5c506b2e

I confirm this fix is verified in Firefox 107.0b6(build ID: 20221027185833) on Windows 10 and Windows 11.