Fullscreen window occludes Windows taskbar even when not in foreground
Categories
(Core :: Widget: Win32, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: d6652702, Assigned: rkraesig)
References
Details
(Whiteboard: [win:fullscreen])
Attachments
(5 files, 1 obsolete file)
bug.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
open a new window | then play any video but "fullscreen"
now switch to another window {firefox window }
now the taskbar dissappears and is replaced by the fullscreen video's bottom portion
Actual results:
now the taskbar dissappears and is replaced by the fullscreen video's bottom portion
*it happens only when two firfox windows are open in order *
Expected results:
the task bar should have remained visible
|
||
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
how do i revert it ????
plz just tell me how to solve issue or plz help
|
||
Updated•3 years ago
|
|
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 4•2 years ago
|
||
Simplified repro procedure:
- In a new window, visit the URL
data:text/html,<body bgcolor="magenta">. Press F11 to make this window fullscreen. - Bring a different, non-fullscreen Firefox window into the foreground (or open a new one), leaving the magenta window in the background.
Fullscreening the first window hides the taskbar; switching to the second window leaves it hidden. This contrasts with the behavior exhibited if, in step 2, a new Notepad window is opened instead, in which case the taskbar will be revealed.
The original report shows a special case where the second window is also maximized. If this happens, the window is sized correctly -- i.e., excluding the space for the taskbar -- but the taskbar is not actually drawn. (Video playback is not required, nor does it seem to matter which order the windows are opened in.)
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 5•2 years ago
|
||
Only tell Windows to allow a fullscreen window to occlude the taskbar
when it also happens to be the active window.
Provide a preference widget.windows.alternate_fullscreen_marking
(defaulting to true) which will revert this behavior in case of
unforeseen side effects.
Note that this does not quite bring Firefox's behavior in line with
other applications. If the taskbar is present on the same monitor as the
fullscreen window, but focus changes to a window on a different monitor
without using Alt-Tab, the taskbar will be immediately revealed. (The
usual behavior is that the taskbar remains occluded until some other
trigger occurs.)
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 6•2 years ago
|
||
For future reference:
This is a Windows bug – or at least a Windows questionable-design-decision – and a fairly longstanding one, at that: Windows doesn't properly distinguish between two windows in the same process (or possibly merely on the same thread) when one of them is marked as fullscreen.
This isn't as simple as "all windows on that thread cause the taskbar to be hidden if active"; as noted above in comment 4, the behavior gets more complicated in the presence of windows from multiple processes. If a fullscreen Firefox window is directly under a non-fullscreen Firefox window, the taskbar will be hidden; but if there's another window Z from another process between them, the taskbar will be visible, even if Z is also marked as fullscreen.
As it's Windows-internal code making the decisions here, the exact failure modes are somewhat difficult to characterize. An upcoming patch will hopefully avoid the need to do so.
|
|
Assignee | |
Comment 7•2 years ago
|
||
Add a global hook and per-nsWindow handlers for cloaking events.
(Other than caching the cloak-state in-process, these don't actually do
anything yet. User-visible functionality will be added in a following
commit.)
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 8•2 years ago
|
||
This function has been unused since bug 1274663 (commit db5cc36763c1).
Depends on D144222
|
|
Assignee | |
Comment 9•2 years ago
|
||
A few drive-by improvements:
-
There's no need to use window properties for this -- it's actually
kind of slow, since it involves a kernel call (NtFindAtom). Use an
in-process hash table instead. -
No caller checks the return value of
Set..., and they couldn't do
anything with it even if they did. Convert it tovoid. -
The distinction between
Get...BasePtrandGet...Ptrwas lost
with the removal ofnsWindowBase(and, arguably, long before).
Collapse them, rename them appropriately, and rewrite the associated
comments. In particular, remove the description of the latter as a
"legacy api". -
Confirm and document that these may only be used on the main thread.
(This was always true, in the sense that it's inherently racy -- a
caller not on the main thread could get the pointer, but the
underlying object might vanish before anything could be done with
it.)
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 10•2 years ago
|
||
Use an undocumented property of an underdocumented property to keep
Windows 7 from detecting effectively-fullscreen windows as fullscreen.
Provide a preference widget.windows.fullscreen_marking_workaround
(defaulting to true) which can be used to disable this hack in case of
unforeseen side effects.
Depends on D144222
|
|
||
Updated•2 years ago
|
|
|
||
Comment 11•2 years ago
|
||
Comment on attachment 9276478 [details]
Bug 1732517 - [2/5] Add cloaking event listener r?handyman,cmartin
Revision D146324 was moved to bug 1647161. Setting attachment 9276478 [details] to obsolete.
|
||
Comment 12•2 years ago
|
||
Pushed by nfay@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/cd365892b9da [1/5] Drive-by cleanup: simplify WinUtils::GetNSWindowPtr() et al. r=cmartin https://hg.mozilla.org/mozilla-central/rev/b90216aecc61 [3/5] Decouple Firefox/Windows fullscreen state r=handyman https://hg.mozilla.org/mozilla-central/rev/2741e9ce9ea6 [4/5] Fix fullscreen marking on Windows 7 r=handyman https://hg.mozilla.org/mozilla-central/rev/aeea6177cbd4 [5/5] Drive-by cleanup: remove EnumAllWindows r=handyman
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/cd365892b9da
https://hg.mozilla.org/mozilla-central/rev/b90216aecc61
https://hg.mozilla.org/mozilla-central/rev/2741e9ce9ea6
https://hg.mozilla.org/mozilla-central/rev/aeea6177cbd4
Description
•