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

Steps to reproduce:

Minimized Firefox when in full screen using Windows 10 toolbar controls.

Actual results:

When restoring back to full screen the bottom taskbar remains stuck. It seems to work the first time it's tried but then fails on subsequent attempts. It does work properly however if Windows key + M is used to minimize the browser instead.

Expected results:

The taskbar should have dropped down to restore the browser to full screen.,

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I can't reproduce this, either by clicking the minimized window's title on the taskbar or by cycling to it with Alt-Tab.

Given the old-style Start button, I suspect you're using Open Shell (née Classic Shell) or some other Windows shell replacement. Is that the case? If so, does the bug still occur when the standard Windows shell is used?

Should have mentioned it's still doing it with Open Shell closed and the use of the standard toolbar. For me it just started in 110, ESR 102 does not have this problem.

Could you run mozregression to see when this started happening?

A number of Firefox versions will open in succession to narrow down when this started occurring. Simply answer "good" or "bad" based on whether or not a build reproduces the bug. Once finished, please post the output from the last run. It should give a last good and first bad revision as well as a link to look at the changesets in that range. Thank you!

A mozregression was not done however I did go back on the nightly builds and actually it first appeared on the November 14th build, which was your first 109.0, the last 108.0 nightly was fine. Most of my nightly runs are in Windows 7, rarely do I even use Windows 10 and so that's why I'm just now seeing it.

Could you run mozregression? This could help us identify the precise change that caused this.

Hello, it took me a while to find the right mozregression.exe because I only have Python 2.7 installed but did finally manage to get it. It is showing this bug as the start of the break:

https://phabricator.services.mozilla.com/D161982

That does look plausible: in this case it would call SetSizeModeInternal without any corresponding call to mWindow->OnFullscreenChanged, and the latter is responsible for calling into TaskbarConcealer to ensure that the taskbar is in the appropriate state. (Setting bug attributes appropriately.)

I'm not sure why I can't repro, though. How are you restoring the window from its minimized state?

Normally it's restored from the taskbar.

I could repro in win11.

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

I could repro this on my Windows laptop but not on my Windows desktop
machine. Why? I'm not sure.

In any case, dispatching fullscreen changes to Gecko based on
the size mode rather than mFullScreenMode is:

• What other platforms do.
• What the taskbar concealer (per comment 2) and probably also other
  code expects.
• Generally saner? The notification order before the regression didn't
  quite make sense, and can end up making other code think we're in
  fullscreen when minimized or what not. It's better to keep
  mFullScreenMode just this internal-to-nsWindow state that makes us
  end up with the right size mode when restoring windows.

https://hg.mozilla.org/mozilla-central/rev/2df5711d3c2a

What are your thoughts on uplifting this to Beta, Emilio?

Comment on attachment 9310109 [details]
Bug 1806438 - Notify of fullscreen changes from SetSizeModeInternal. r=cmartin,rkraesig

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?: Yes
• 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): This code is rather subtle, but I think the patch is rather targeted and shouldn't involve much risk.
• String changes made/needed: none
• Is Android affected?: No

I have reproduced this issue on Win 10 x64, with an affected Nightly build from 2022-12-19.

I've checked the fix on latest Nightly 110.a01, and it seems that the taskbar does not remain displayed anymore after restoring Firefox from its minimized state.

However, I need to left click 3 times on the Firefox icon in order to restore the browser window, see screenshot here. Emilio, can you please take a look at this?

Comment on attachment 9310109 [details]
Bug 1806438 - Notify of fullscreen changes from SetSizeModeInternal. r=cmartin,rkraesig

Let's not uplift till we've figured that out.

And centralize more sizemode change code in SetSizeModeInternal instead.

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

This problem has returned even worse than before. No longer is Win + M a workaround, it sticks no matter the method of minimizing while in full screen. Can this bug be re-opened or should a new one be filed?

Please file a new one with details on what FF and Win version are you reproing this in.