Open Bug 1963606 Opened 17 days ago Updated 4 days ago

On Windows 10, taskbar sometimes present when video is on full screen

Categories

(Core :: Widget: Win32, defect)

Firefox 138
defect

Tracking

()

UNCONFIRMED

People

(Reporter: egecet05, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Attached image Result.png

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

Steps to reproduce:

Open any YouTube or any other platform (Prime, Max) video.
Set the video to full screen from video controls and not F11.

Actual results:

Windows taskbar is present over the video

Expected results:

Video should take full screen.
This problem is not seen on F11 full screen and also started happening after updating to Firefox 138.
This problem is not seen on my laptop which is native 1920x1080 but is present in my PC which has 2560x1440 monitor.

Ran mozregression and the result is like this:

Narrowed integration regression window from [6388b6c5, b2b4ffbf] (3 builds) to [6388b6c5, 8a36c90d] (2 builds) (~1 steps left)
2025-04-30T17:20:30.602000: DEBUG : Starting merge handling...
2025-04-30T17:20:30.603000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=8a36c90dc47ddb9152ab794ebc89347684045fc9&full=1
2025-04-30T17:20:30.604000: DEBUG : redo: attempt 1/3
2025-04-30T17:20:30.604000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=8a36c90dc47ddb9152ab794ebc89347684045fc9&full=1',), kwargs: {}, attempt #1
2025-04-30T17:20:30.606000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-04-30T17:20:31.554000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=8a36c90dc47ddb9152ab794ebc89347684045fc9&full=1 HTTP/11" 302 0
2025-04-30T17:20:33.040000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=8a36c90dc47ddb9152ab794ebc89347684045fc9&full=1 HTTP/11" 200 None
2025-04-30T17:20:33.042000: DEBUG : Found commit message:
Bug 1950441 - mark windows as (not) fullscreen via different mechanism r=win-reviewers,handyman

As noted in bug 1949079, Windows appears to detect maximized windows
with custom titlebars as "full screen", and hides the taskbar behind
them when autohide is enabled. (This appears to have been due to a
recent change to their explicitly undocumented heuristics, but we may
also have triggered it somehow with the recent-ish refactor of the
custom non-client area.)

To avert this, resurrect another mechanism to mark windows as
fullscreen: "NonRudeHWND". This was previously believed -- perhaps
correctly, at the time -- to be unusable on Windows 10; but recent
testing shows that it does work, even in several of the cases where
the existing mechanism fails.

Just in case it doesn't and I was right the first time, guard this
behind a pref and allow users to switch back to the flaky mechanism.

Differential Revision: https://phabricator.services.mozilla.com/D239658

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

Component: Untriaged → Graphics
Product: Firefox → Core

Can you go to about:support and click the Copy text to clipboard button, then click Attach New File on this bug and paste it there? It would be helpful to know windows version and other details.

On Windows 11 build 26100 I tried each value of widget.windows.fullscreen_marking_method:
0 : no taskbar
1 : taskbar
2 : no taskbar
3 : no taskbar

I'm guessing the behavior differs on other Windows 11 builds or Windows 10 builds, so I'd like to know the windows build number (which is in about:support) where this is not working correctly.

Flags: needinfo?(egecet05)
Regressed by: 1950441
Component: Graphics → Widget: Win32
Keywords: regression

Here's the text from about:support page. Not sure if it's about windows build as my laptop which does not present the issue is on the same build.

Flags: needinfo?(egecet05)

Ege, there is a setting that ahale mentioned in comment 3 that would be good to know how it affects you. Can you try changing it and posting what happens?

To change the widget.windows.fullscreen_marking_method setting:

  1. Go to about:config
  2. Accept the risk and continue
  3. Enter widget.windows.fullscreen_marking_method into the search field.
  4. That pref should show up, presumably set to 0. Valid settings are 0, 1, 2, or 3. Change the setting to each one of those numbers and press enter, then restart the browser and try to reproduce the bug.

This will tell us if any of the ways of telling Windows that the window is fullscreen will convince it to remove the taskbar. (You may want to reset the setting to 0 when you are done.)

Flags: needinfo?(egecet05)

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

Ege, there is a setting that ahale mentioned in comment 3 that would be good to know how it affects you. Can you try changing it and posting what happens?

To change the widget.windows.fullscreen_marking_method setting:

  1. Go to about:config
  2. Accept the risk and continue
  3. Enter widget.windows.fullscreen_marking_method into the search field.
  4. That pref should show up, presumably set to 0. Valid settings are 0, 1, 2, or 3. Change the setting to each one of those numbers and press enter, then restart the browser and try to reproduce the bug.

This will tell us if any of the ways of telling Windows that the window is fullscreen will convince it to remove the taskbar.

Hi David, just tried the settings, 2 and 3 are giving me the expected results and 0, 1 are still bugged.

Flags: needinfo?(egecet05)

Thanks, that is a huge help. We'll have to figure out how to make this work for everyone but, in the interim, you can leave the value set to 2 or 3.

Summary: Taskbar present when video is on full screen → On Windows 10, taskbar sometimes present when video is on full screen

You might also want to try Firefox NIghtly to get the latest fixes. You might be seeing this bug, which was apparently fixed in Fx 139, so the fix will appear in the next release. That comment also has some other settings to try. If you do get a chance to do that, let us know if any of it works for you!

Severity: -- → S3
Severity: S3 → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: