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

Steps to reproduce:

Go to www.youtube.com
Open any video
Enter full screen

Actual results:

The video goes full screen but the taskbar still shows at the bottom. Going to another window and back to firefox fixes the issue

Expected results:

The task bar should be hidden when video goes 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.

Thanks Farooq. This issue may be fixed in Firefox Nightly. Can you try downloading and running that and letting us know what happens?

If that doesn't work then there are some preferences that you might experiment with to see if they fix the issue for you:

• Go to about:config (and accept the warning) and type the preference name "widget.windows.fullscreen_marking_method" (no quotes) into the search field. It will allow you to enter a number for that pref between 0 and 3. If (after restart) any of those values work for you, let us know.
• You could also try changing the prefs that worked here.

Thanks again. Let us know what you find!

Hi David,
I changed the "widget.windows.fullscreen_marking_method" config to 2 in my current version of firefox and that seems to fix the issue. The old value was 0.
I installed Firefox nightly and it looks like the bug is still there. I'll just use the config fix for now then.
Apologies for the duplicate bug report. I didn't know about the other one.

I've also upgraded firefox to version 139.0b7 and the issue still persists with the default config value

I'm having the same issue. Running 138.0.1 win10

setting "widget.windows.fullscreen_marking_method" to "1" or "2" fixes the issue for me. Setting it to "0" or "3" does not.

If possible, could anyone explain what the different values (1,2,3) of "widget.windows.fullscreen_marking_method" are?

(I have it currently set to 2 to avoid this bug, but not sure what the consequences are. Would I be better off if I set it to 1 instead, for instance)

You are safe leaving it set to any value that works for you. It just chooses between the method(s) that Firefox uses to tell Windows that the window is not fullscreen. It will only affect Firefox's relationship with the taskbar. There is a bit more info on that here (although the definition of '0' now internally matches the definition of '3', despite what the comment says). We're probably going to change the default to '2', although we believe that won't always work either.

(In reply to David Parks [:handyman] from comment #8)

You are safe leaving it set to any value that works for you. It just chooses between the method(s) that Firefox uses to tell Windows that the window is not fullscreen. It will only affect Firefox's relationship with the taskbar. There is a bit more info on that here (although the definition of '0' now internally matches the definition of '3', despite what the comment says). We're probably going to change the default to '2', although we believe that won't always work either.

Can detect work as 2 && 3 (if one of these is true = taskbar is visible. or something like that)?

In which release you will turn back 2 as default?

thnks

Set Regressed By from duplicate bug

The severity field is not set for this bug.
:handyman, could you have a look please?

For more information, please visit BugBot documentation.

I was able to reproduce this issue as well on a Windows 10 machine with a 1080p monitor but only if I set the "widget.windows.fullscreen_marking_method" to "1" .

Also got a regression range for this issue:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=0585ab26c3b3612f0549a72d20e6d4552a3a54d1&tochange=f7c403094a8960c705fc15b46683289e02e2414d

I will update the flags for this issue.

We expect this to work properly for more users but see bug 1949079 for known
failure cases.

https://hg.mozilla.org/mozilla-central/rev/593a89d2b86d

The patch landed in nightly and beta is affected.
:handyman, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox140 to wontfix.

For more information, please visit BugBot documentation.

Hi @David, I am still able to reproduce this issue in our latest Nightly build 20250617092639 if I set the "widget.windows.fullscreen_marking_method" to "1" . Was the push for this fix backed out ? I grabbed the latest mozilla central build from our treeherder :
https://treeherder.mozilla.org/jobs?repo=mozilla-central&selectedTaskRun=WU6sTh40RCObK5ruBDNWnQ.0

David's change just updated that pref to be 2 by default, so even if you have a build without his change, setting the pref to 2 will have the same effect. Can you still reproduce with the pref set to 2?

I cant reproduce this issue when I set that pref to 2. I will update the flags for this issue since its verified as fixed in our latest Nightly build.

:gstoll, is this safe for a release uplift request as a ride-along in a later dot release?

I think so. There's some black magic going on here, but most people that have reported this problem say that this change (setting the pref to 2) fixes the issue for them. I'm a little worried about breaking other people, but I'm not sure that would be any worse than what we're doing now.

Actually, since the bug is already in release (since 138), everyone who was going to have a problem has it already, but we don't know what the change will do, and we are late in the beta cycle, so we are thinking that this should not get uplift. NI to dmeehan to note of this.