Open Bug 1957069 Opened 11 months ago Updated 1 month ago

Firefox prevents Windows taskbar from appearing when taskbar is set to auto-hide.

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Version:
Firefox 136
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: WPeyser, Unassigned)

References

Details

Attachments

(3 files)

Error message
15.16 KB, image/png
Details
The log
149.71 KB, text/plain
Details
WIP: Bug 1957069 - Mark pre-xul skeleton UI window as not hiding the taskbar.
48 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

Started up Firefox.

Actual results:

The Firefox window, when first opened, prevents the Windows taskbar from appearing when the taskbar is st to auto-hide. The Firefox window must be minimized, then maximized, in order to allow the taskbar to appear. This happens every single time Firefox starts up. This is a new bug in the latest Firefox versions.

Expected results:

Firefox, when started up, should not prevent the Windows taskbar from appearing when the taskbar is set to auto-hide. The Firefox window should not have to be minimized, then maximized, in order to allow the taskbar to appear.

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.

Component: Untriaged → Widget: Win32
Product: Firefox → Core

Hi WPeyser,

Is this a new issue for you? You said that you have to minimize, then maximize, to get the taskbar back -- it sounds like this is starting-Firefox-maximized, then minimizing (which presumably restores the taskbar), then maximizing but this time getting the taskbar? What happens if you restore a session that wasn't isn't maximized, then maximize it? And, what happens if, instead of minimizing, you just click the restore down button?

If the problem is new, can you try running mozregression to see if you can determine when the bug was introduced? In case you haven't used it before, there is a video at that link that explains how to use it -- you just need to specify a date when you believe there was no bug, and then check the versions of Firefox that it downloads and executes to see if they show the bug. Then you can just paste the pushlog_url that it gives into this bug. There's been a fair amount of work regarding the taskbar recently, so this should help narrow things down. Thanks for the help!

Flags: needinfo?(WPeyser)

Let me - I am not the original reporter - add the following.

  1. The Internet contains many reports of a problem along these lines, though at least some of the reports seem to indicate some sort of user error.

  2. I have had the problem - which does not seem to be my fault - for at least a few versions of Firefox (those versions being 'release' versions, all of them running on Windows 10). For, I encounter the following behaviour. When Firefox is maximised, but not in full-screen mode, the Windows taskbar does not pop-up over the Firefox window until one toggles full-screen (on and off again); and, soon, the problem reoccurs. The problem occurs when the pinned taskbar icon that I have for Firefox is set to launch Firefox in what the launcher settings call a 'normal' window but also when that setting is set to 'maximized'. The problem it is a considerable inconvenience.

Thanks. That problem does sound similar -- assuming that your taskbar is set to auto-hide. Is that the case? If you can run mozregression and post the results, that would help narrow it down.

Flags: needinfo?(nicholasjoll)
Duplicate of this bug: 1958919

stur2006, can you try the steps in comment 2 and post your results?

Flags: needinfo?(stur2006)

handyman: yes, my taskbar is set to auto-hide. I am unfamiliar with 'mozregression': please explain or point me towards a good explanation.

Flags: needinfo?(nicholasjoll)
Flags: needinfo?(davidp99)

Thanks. Mozregression is linked in comment 2 -- there is a video there that explains the process but it's not very complicated. You just pick a build (by version #, date, etc) that you think didn't have the bug and it will download and run builds for you to reproduce the issue in. You tell it which builds are good and which are bad, and it figures out when the problem was caused. If you don't have any idea what to use for the start date, given what I know of this bug, I'd suggest going back to at least 8 months ago.

Flags: needinfo?(davidp99) → needinfo?(nicholasjoll)

Thanks.

Mozregression-gui threw an error the first time that I ran it (it, not its installer) and pointed me towards a webpage where I could file a bug - which was not the GitHub repository from which I obtained the tool, and the page I landed on contained no obvious way to file a bug. All of that is not good, especially since the problem turned out to be merely that I had not allowed the program through my firewall. Nor is the GUI intuitive. But there was the video, which sufficed. So . . (But, within mozregression, the text 'let this blank' should be 'leave this blank'. And the back button, at least on Windows 10 in dark mode, is nearly invisible. More: the tool seems not to show how many versions of Firefox it is going to download. But the idea of the tool is nifty.)

Given that bug is intermittent, especially in when - during a Firefox session - it starts to manifest itself, I had to be patient and I was unsure how patient I should be, or wanted to be. Also, of course: there might be some specific user behaviour, or configuration, that is not getting reproduced when I use the mozregression downloaded-builds.

Also, when testing one build, I saw the error I attach in a screenshot. I had to skip that version. I was offered a substitute. That version gave the same error. After that had happened a few times, Mozregression halted the test. I attach the log.

Flags: needinfo?(nicholasjoll)
Attached image Error message —
Attached file The log —

So.... the on-screen log from "mozregression GUI":

2025-04-11T14:28:51.661000: DEBUG : Found commit message:
Backed out changeset 11021e45484d (bug 1924576) for causing ESlint failure at browser_syncedtabs_sidebar.js. CLOSED TREE

2025-04-11T14:28:51.661000: DEBUG : Did not find a branch, checking all integration branches
2025-04-11T14:28:51.677000: INFO : The bisection is done.
2025-04-11T14:28:51.677000: INFO : Stopped

The push-log URL:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74fc528d64f449162e2eda609969a49e96c0965b&tochange=ab543854c3d899d2a6c1f73d60e931d990194708

Hope this is what you're asking for, let me know if you want something else...
Sorry for the slow response.

Flags: needinfo?(stur2006)

Thanks to both of you. The log that stur2006 found looks pretty conclusive. That gives me what I expect from mozregression. At the moment, the main suspect is bug 1935894.

One additional request -- can you try running the latest Firefox Nightly (bottom of the page), assuming you weren't doing that before, to see if you can reproduce the issue there? That will tell us if this bug has been fixed by some things that have happened more recently.

Thanks for sticking with this.

Flags: needinfo?(WPeyser) → needinfo?(stur2006)

Hi David

I've had the latest nightly running for an hour or so. Mostly I had it sit in the background but I did play around with it a bit. I did _not _encounter the taskbar problem on that build.

Sorry, I replied via email... :S

Just tried Firefox Nightly 139.0a1. Snapping the window to the top of the screen no longer causes the issue. However, starting FFN maximised still restricts the taskbar.

Flags: needinfo?(stur2006)

I tried to reproduce the problem Firefox Nightly 139.0a1 when starting Firefox maximized. I did not manage to.

Steps to reproduce:

  1. Restore Down Firefox Nightly (FFN)
  2. Maximise FFN either by snapping the window to the top of the screen or the maximise button.
  3. Make sure that the taskbar has disappeared and is fully hidden.
  4. Close the window. Make sure all FFN windows are shut down.
  5. Wait a few seconds, or click somewhere blank on the desktop.
  6. Re-launch FFN either from a desktop icon or an icon pinned to the taskbar.
    If launching from a desktop icon, do not move the mouse towards the taskbar until FFN is fully up and running.

Stur2006: thanks.

I managed to reproduce the problem using those steps (though I do not understand step 1 and, departing slightly from step 6, I launched the nightly version, the second time - and indeed the first time - via the Start menu or rather via the program called 'Open Shell').

Thanks again. This is useful, even if though steps don't reproduce the issue for me. Maybe this is about opening the window instead of maximizing/minimizing it. There may also be a way to check the issue from comment 17 with mozregression, but since step 4 involves restarting the browser, it would take a lot of juggling to reproduce. emilio, any thoughts on this?

Flags: needinfo?(emilio)

I just tested the opening/running issue, and my steps to replicate are somewhat superfluous. I will add for clarity. When I tested with FFN, the bug seemed intermittent. Sometimes I closed the window and restarted the browser, and the hidden taskbar was bugged. Sometimes I closed the window (in the bugged state with no accessible taskbar), and then reopened the window as quickly as possible, but when the window reopened, the taskbar was no longer bugged. This was confusing at first, as it appeared that I could not replicate the bug without the min/max/pause (Steps 1/2/3). However, closing the browser, giving it a few seconds for any potential standby memory to release, then reopening it, replicates the problem; When Firefox nightly opens, the hidden taskbar is not accessible. I don't know if a rapid close/reopen would act as a minimise/maximise function, but the bug is there on a fresh launch. I'll leave it with you, I don't want to waste your time and hope it's helpful. Sorry for any confusion.

Hmm, so we seem to be tripping some of the windows heuristics to detect a window being fullscreen vs. maximized... I don't have a lot of context on the TaskbarConcealer code but my understanding is that that's supposed to be able to deal with it.

However TaskbarConcealer::OnWindowMaximized doesn't seem to do anything by default... I wonder if we need to enable it even if we're also using the NonRudeHWND bit?

Reporter (or others that can reproduce the issue), can you try to go to about:config and set widget.windows.fullscreen_marking_method to 1, 2, and 3, and see what the behavior is?

My expectation is that 2 might fix it... In which case we need to make this condition broader perhaps?

Flags: needinfo?(emilio) → needinfo?(WPeyser)
See Also: → 1952284

Tested on Firefox Nightly 139.0a1

Setting widget.windows.fullscreen_marking_method to 1
Taskbar is inaccessible on launch. Snapping or restoredown/min/max makes the taskbar accessible.

Setting widget.windows.fullscreen_marking_method to 2
Taskbar is inaccessible on launch AND when snapping window. Restoredown/min/max makes the taskbar accessible.

Setting widget.windows.fullscreen_marking_method to 3
Taskbar is inaccessible on launch. Snapping or restoredown/min/max makes the taskbar accessible.

Flags: needinfo?(emilio)

So I can't reproduce this but based on code inspection seems like this should work. Can someone who can reproduce this issue try a build from here and report back?

https://treeherder.mozilla.org/jobs?repo=try&revision=c19bbd24e60930aa809e69cf6eb885d391f2a63c

Flags: needinfo?(emilio) → needinfo?(stur2006)

Sorry, 100% noob here. I tried looking it up, but I will need instructions for what I am looking at/doing with that link.

Flags: needinfo?(stur2006) → needinfo?(emilio)

Yeah sorry I usually link directly to a zip file but the build wasn't finished. If you click on the build task (B), then "Artifacts and debugging tools", you can see an installer and a zipfile. Here's one for the previous build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JVOFyhY0ScOvAWxTNkwnWQ/runs/0/artifacts/public/build/target.zip

Flags: needinfo?(emilio) → needinfo?(stur2006)

Installed from "target.installer.exe".
The taskbar is still inaccessible when opening the browser maximised.

Uninstalled Firefox Nightly and reinstalled using "target.installer.exe".
The taskbar is still inaccessible when opening the browser maximised.

Ran the firefox.exe from the extracted "target" folder.
The taskbar is still inaccessible when opening the browser maximised.

Any files or folders I need to delete to make sure I'm getting a 100% clean install?

Flags: needinfo?(stur2006)
Duplicate of this bug: 1961282
Duplicate of this bug: 1961567
Severity: -- → S3

Seems like the issue is back. I rebooted my PC, instantly launched FF and the taskbar was hidden once again. Actual 140.4 version

I have had this bug for many months. The only "fix" I have found is to enable the Title Bar but that takes up screen space.

This bug seems to randomly come and go with releases for me. It was present in 137, fixed in 138, 139, 140. Broken again in 141.
Bug was NOT present on Firefox 140.4. After today's upgrade to Firefox 141 the bug is back. (It is also broken on current Nightly)

My machine: Windows 10 [Version 10.0.19045.6093], Nvidia 566.36. Resolution 1920x1080. Display scaling@125%.

Details:
FF140.4 -- Maximising the FF window by any means always allows the user to hover over their chosen 'hot row' of pixels to unhide the Windows taskbar. (taskbar is set to auto-hide in Windows settings)

FF141. -- Maximising the FF Window by pressing the 'Maximise' window decoration works as expected.
Double clicking the tab bar OR dragging the window to the top of the screen OR using Windows Key + Up arrow causes the Firefox window to draw over the taskbar or somehow not allow the mouse to interact with the hot row of pixels. Note, it is obvious the bug is present because said pixel row is no longer visible.

Can you try the steps in comment 2 for running Mozregression, to see what caused the problem to return? (You can use Firefox 140.4 as the last-known good version.) At the moment, we don't know what affected this, and that should help ID the culprit. The "full screen marking method" has changed recently but comment 22 suggests it's not responsible.

Flags: needinfo?(ecan0qvsh)

Last known good: 2025-06-16
Bisect: [87e010eb, b0355500]
Bad: 2a6675e9

Pushlog:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=87e010ebac62c5bed9a41c64e63df5be347f65e6&tochange=b03555008151d6d19fca7e8986f4c206074e7a82

App log:

`2025-07-22T05:59:22.616000: INFO : Narrowed integration regression window from [87e010eb, b0355500] (3 builds) to [87e010eb, 2a6675e9] (2 builds) (~1 steps left)
2025-07-22T05:59:22.631000: DEBUG : Starting merge handling...
2025-07-22T05:59:22.632000: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=2a6675e95277b3795a774a09e529ae8566eee68e&full=1
2025-07-22T05:59:22.635000: DEBUG : redo: attempt 1/3
2025-07-22T05:59:22.635000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/mozilla-central/json-pushes?changeset=2a6675e95277b3795a774a09e529ae8566eee68e&full=1',), kwargs: {}, attempt #1
2025-07-22T05:59:22.637000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-07-22T05:59:23.271000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /mozilla-central/json-pushes?changeset=2a6675e95277b3795a774a09e529ae8566eee68e&full=1 HTTP/11" 302 0
2025-07-22T05:59:23.914000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /mozilla-central/json-pushes?changeset=2a6675e95277b3795a774a09e529ae8566eee68e&full=1 HTTP/11" 200 None
2025-07-22T05:59:23.916000: DEBUG : Found commit message:
Revert "Bug 1952913: Directly link contiguous SessionHistoryEntrys. r=farre,dom-core" for causing several webdriver failures.

This reverts commit fd17667df636d50199f36f4986ad1807b923658a.

2025-07-22T05:59:23.920000: DEBUG : Did not find a branch, checking all integration branches
2025-07-22T05:59:23.921000: INFO : The bisection is done.
2025-07-22T05:59:23.922000: INFO : Stopped`

Flags: needinfo?(ecan0qvsh)

Here is the same issue but going from build 136 to 137.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74fc528d64f449162e2eda609969a49e96c0965b&tochange=ab543854c3d899d2a6c1f73d60e931d990194708

2025-07-22T06:39:28.487000: INFO : Narrowed integration regression window from [8a8b1eff, ab543854] (3 builds) to [8a8b1eff, 04fab133] (2 builds) (~1 steps left)
2025-07-22T06:39:28.499000: DEBUG : Starting merge handling...
2025-07-22T06:39:28.500000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=04fab1333981a90d13cc1d0e221ef6cd6dcd48be&full=1
2025-07-22T06:39:28.501000: DEBUG : redo: attempt 1/3
2025-07-22T06:39:28.502000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=04fab1333981a90d13cc1d0e221ef6cd6dcd48be&full=1',), kwargs: {}, attempt #1
2025-07-22T06:39:28.508000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-07-22T06:39:29.169000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=04fab1333981a90d13cc1d0e221ef6cd6dcd48be&full=1 HTTP/11" 302 0
2025-07-22T06:39:30.431000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=04fab1333981a90d13cc1d0e221ef6cd6dcd48be&full=1 HTTP/11" 200 None
2025-07-22T06:39:30.433000: DEBUG : Found commit message:
Backed out changeset 11021e45484d (bug 1924576) for causing ESlint failure at browser_syncedtabs_sidebar.js. CLOSED TREE

2025-07-22T06:39:30.433000: DEBUG : Did not find a branch, checking all integration branches
2025-07-22T06:39:30.436000: INFO : The bisection is done.
2025-07-22T06:39:30.437000: INFO : Stopped

It doesn't initially seem like the changes correlate but the same bug exists within this range also.

I went back through the posts and tried altering the widget methods using build 141. It had no effect on the bug but I feel like Comment 22 is perhaps on the right track. Maybe there is some condition where a Maximised Window when initiated via double click/drag to top of screen is being treated as Fullscreen (F11)?

Sorry, I meant Comment 21. Can't find a way to edit posts here, not used this system before.

Duplicate of this bug: 1978627

Me today:

Steps to reproduce:
On Windows 10 with auto-hide taskbar enabled, the taskbar no longer appears when hovering the mouse at the bottom of the screen in Normal Browsing and Private Browsing mode, starting with Firefox 141 Candidate Build 2 and now on Full 141 and 142 beta 1.

This issue is not present in:
Candidate Build 1 of Firefox 141 Normal Mode (Private Mode still have this bug)
Firefox 140 or 139 (fully working on normal and private Mode)

I verified this by swapping only the xul.dll file from Candidate Build 1 into Build 2 – and the taskbar behavior is restored (Not in Private Mode).
Steps to reproduce:
Use Windows 10 with taskbar set to auto-hide.
Open Firefox 141 (Candidate Build 2 or newer).
Open a Private Browsing window.
Move mouse to the bottom of the screen – taskbar does not appear.
Replace xul.dll from Candidate Build 1 to Build 2 – behavior is restored in Normal mode.

BUG is present in xul.dll for sure.

Thanks all. That indicates the problem is bug 1965699. Since this worked for you in Fx 140, you can probably get past the bug by changing the fullscreen-marking-method setting mentioned in comment 21 to 0, which it was before bug 1965699. However, comment 22 suggests that won't work for everyone.

Developer notes: The marking method behavior changes started with bug 1949079, for Fx 135, and appeared in Fx 137. Fx 135 seems to have introduced the Win10 taskbar issue . If Fx 135 originated the bug then the changelog is hard to analyze but bug 1930292 may be involved.

Setting aboute:config widget.windows.fullscreen_marking_method to 0 or 1 fixed my issue in FF 141.

The latest version without this problem is firefox-141.0a1.en-US.win64.installer.exe 77M 17-Jun-2025 01:23.
Starting with version firefox-141.0a1.en-US.win64.installer.exe 77M 17-Jun-2025 12:58 there is a problem.

Now I set widget.windows.fullscreen_marking_method = 0 and everything seems to work.
(firefox-143.0a1.en-US.win64.installer.exe 80M 22-Jul-2025 12:05)

Now that someone mention it, my FF's ALWAYS maximized, if it helps

Now it's worse on the new 141 version. Once ya start the app it'd hide the taskbar as it now happens here and there again.

However, now if this happens and press the Windows key it'll make the taskbar visible again. HOWEVER if you MINIMIZE the window and, let's say, open a link from Discord, the minimized FF session will appear again, BUT THE TASKBAR WILL BE HIDDEN AGAIN

Revisiting this bug -- setting widget.windows.fullscreen_marking_method = 0 does work for me here on Windows 10 but I need to restart Firefox or press the Start button (thus un-hiding the taskbar) at least once after making the change to the about:config flag.

Tested on 141 release and 143.0a1. Maybe default this flag back to 0 (Win10) until the bug is fully fixed/investigated.

This preference is set to 0 by default in about:config, and it has no effect at all for me using Windows 10.

It is default 0 in Fx140. In Fx141 it gets changed to default 2. Checked using builds via mozregression.

Duplicate of this bug: 1978630

The new update from today? (141.0.2) has the issue still

141.02 same issue

Defaults to 2 when it should be 0, Multiple systems have issues as such I manual change to 0 and the setting stick across builds for 141.xx not sure if it will stick going to 142 but I would assume it would, I really dont get how got fixed back with 138.xx cause it broke all threw 137.xx and then it got broke again by it be changed back. if widget.windows.fullscreen_marking_method = 2 has always been it defualt something else behind scenes in firefox it broke.

I do know Thunderbird 140.1 esr default for this setting is 0

The using is on both Windows 11 and 10 systems using current Firefox builds

Another workaround: Hover the mouse over any tab to display the taskbar. No clicks required.

Over any tab?... You mean the top tabs when having multiple pages on?.. Because that doesn't works

I come back here to say that i've installed FF 142 (Stable) and the issue PERSISTS

The issue persists because the geniuses at Mozilla broke their own window, and they don't know how to fix it.

Duplicate of this bug: 1985337

I installed the latest Thunderbird - previously I had Thunderbird ESR - and now I find that I have the problem not only on Firefox but also on Thunderbird. (Also, while hitting F11 a couple of times seems sometimes to clear the problem in Firefox, in Thunderbird F11 brings up a calendar function that I have tried in vain to disable.)

Just set "widget.windows.fullscreen_marking_method = 0" and should be no problem anymore, tested thing on 3 diffrent pc using Current FF and Thunderbird ESR, Main branch of Thunderbird should no diffrent.

Once set you dont have to worry about taskbar not unhiding anymore. short off you reseting the key. cause updates to FF and Thunderbird do not change if it already been set.

As they dont seem to want to just set to 0, which resolves the problem in most case. At this point I think setting it to 0 is just work around for the issue that lies someplace else in FF code but still changing the default to 0 should be really simple thing for them to do.

Though I pretty sure if you look up there is and was regression where it use to 0 got change to 2 then got change back to 0 and now back 2 it not first time they key got swittch around either as it happen back 137.xx was fixed in 138.xx was fine again till 140.xx

(In reply to Ste from comment #47)

It is default 0 in Fx140. In Fx141 it gets changed to default 2. Checked using builds via mozregression.

Hey, that worked out!!.. Now they gotta implement it into a future update so we don't have to do this

Notes this into his list of "About:Config things one should change after formatting" things

Duplicate of this bug: 1985962

Changing windows.fullscreen_marking_method from 2 to 0 has absolutely no effect at all on this bug in my Windows 10 installation. The bug has NOT been repaired. The Windows 10 taskbar, when set to auto-hide, still is prevented from appearing when Firefox is opened maximized.

(In reply to WPeyser from comment #59)

Changing windows.fullscreen_marking_method from 2 to 0 has absolutely no effect at all on this bug in my Windows 10 installation. The bug has NOT been repaired. The Windows 10 taskbar, when set to auto-hide, still is prevented from appearing when Firefox is opened maximized.

this would imply the "windows.fullscreen_marking_method from 2 to 0" is work around for bigger problem they cause behind the scenes, that they dont know what changed in code or worse how to fix it.

For me this fixed problem from multiple machines and one then is windows 10. people that complaint about same issue over on reddit reported windows.fullscreen_marking_method 0 " fixed the problem for them.

I would have shit fit if I had this problem for 5 months, to point I would find old build FF that didnt have that problem and out right disable updates.

Seeing I wont touch chrome or edge

The preference "windows.fullscreen_marking_method" was set to "0" by default when the bug first appeared. Setting it back to "0" has no effect.

I have this issue with Thunderbird 142.0 (64-bit) on Windows 11 23H2. I have the Windows taskbar set to auto-hide and I close Thunderbird with its windows maximized, so it opens up maximized. I use the pinned Thunderbird taskbar button to open Thunderbird.

Setting widget.windows.fullscreen_marking_method to 0 seems to fix the issue, at least at the moment. It was set to 2 by default.

I have the same issue in Firefox 142.0.1 (64-bit). However, changing widget.windows.fullscreen_marking_method to 0 doesn't help. What does help though is to just left-click a blank spot on the tab bar. I tried that trick in Thunderbird by opening a message in a new tab so the tab bar shows and then left-clicked on it, but it doesn't help like it does in Firefox.

The only other program that interferes with the taskbar on my system is Windows Explorer (File Explorer) ever since Microsoft redesigned it not too long ago. Minimizing it and maximizing it again stops it from interfering with the Windows taskbar unhiding. The tab bar trick doesn't work like it does in Firefox.

See Also: → 1965699

Wanted to confirm issue still occurs with version 143.0.4

As I have just found this thread I was unaware of the workaround by adjusting = "windows.fullscreen_marking_method" so I have not yet tried that on any versions.

I can say that like "Ste in comment 33" & "sj.vegetto in comment 50" the problem appears and then disappears depending on the release version.
Using the default windows.fullscreen_marking_method values

100% certain functions flawless in all 140.x.x versions (just regressed back to 140.0.4) & 136 . Does NOT work on 142.0.1 & 143.0.4

Unfortunately the update.xml (update history file) doesn't log when an older version replaces a newer so I can't say w/100% which older versions worked. I would guess i'm in the same camp as Ste as to working/no working versions and is on Win 10 as well
It looks like things took a turn after version 136.

This bug continues to persist in version 144. Changing the value of windows.fullscreen_marking_method has no effect at all.

Hello. I Have disabled the auto updtate in Firefox and I update manually Firefox two or three times a year because each time I make an update, I have to face a new bug introduced in the new version. Having updated from version 135 (which worked fine) to version 143, I had the bad luck to be affected by that taskbar bug that cannot be unhiden when I move the cursor at the bottom of the screen. Do I need to update Firefox once a century ?

(In reply to WPeyser from comment #66)

WPeyser, this is a polite reminder that this is our professional working environment as much as it is our issue tracker, and I'm asking you to refrain from making further comments that don't move this bug towards a resolution.

Please take a moment to review our Community Participation and Bugzilla Etiquette guidelines if you intend to continue contributing to this or other issues.

Please, somebody can tell me if this bug has been fixed in version 145 ?

No, release 145 still includes the same bug.
Probably the Mozilla staff does not read these messages !
On my side, I have by-passed this annoying problem by opening Firefow with the intermediate window state but stretched at its maximum sizes, which are not far from the full-screen size. Doing so, the task bar appears when the mouse is moved down the screen, which is still not the case if Firefox opens in full-screen window.

Thank you for your quick answer cwplayer. My workaround is to open Firefox in maximized window and push the F11 key twice, then the taskbar behaves normally. I am writing a temporary add-on which automates this process when Firefox starts.

it not fixed as I reset the key "windows.fullscreen_marking_method" 2 and it still happens as but seeing setting it to 0 has fixed for me I see no point in reverting the key.

I wont have really remeber this change cause I dont go around make new profiles often

As of 2025-12-23:

This issue is not a user configuration problem but a recurring regression in Firefox’s Windows window-state handling.

On Windows 10, when the taskbar is set to auto-hide and Firefox is launched or used in a maximized window (not F11 fullscreen), the taskbar frequently fails to reappear on mouse hover at the bottom edge of the screen. This does not occur with other applications under the same conditions.

The problem is intermittent and highly dependent on window state transitions (launch state, restore, maximize, snap, focus changes), which strongly suggests incorrect interaction between Firefox’s maximized window behavior and Windows fullscreen heuristics.
Pressing F11 repeatedly (entering and exiting fullscreen) can sometimes cause the taskbar to reappear, but this behavior is inconsistent and clearly not a valid or reliable solution. The fact that fullscreen toggling temporarily affects the outcome further indicates a window state misclassification.

Multiple users (including myself) confirm that:
– The issue persists across several Firefox versions and reappears after being “fixed”.
– Changing widget.windows.fullscreen_marking_method may work temporarily for some users but is not a reliable or permanent solution.
– about:config or user.js workarounds do not consistently resolve the issue.
– Minimizing/restoring or snapping the window temporarily restores taskbar access, confirming a window-state detection problem rather than a taskbar bug.

This behavior effectively breaks a standard Windows feature (taskbar auto-hide) and should not be considered an edge case. The root cause appears to be Firefox incorrectly triggering Windows fullscreen detection for maximized windows under certain conditions.
This issue has existed in various forms for years and remains unresolved in current versions.

Tested on:

  • Firefox 146.0.1 (64-bit)
  • Windows 10 Pro 22H2 (OS Build 19045.3448)
  • Windows Feature Experience Pack 1000.19044.1000.0
  • NVIDIA Studio Driver 591.44
    System:
  • Intel i9-9900K
  • NVIDIA RTX3090

It's certainly not a universal issue, but Firefox isn't the only place I've seen it. I hit a very similar problem years ago (2013, so XP/7 era) in a DX11 experiment; in that case it was (intermittently) triggered by toggling between fullscreen and maximized, but the symptom was the same: autohide taskbar not reappearing when it should.

The only solution I found was a heavy-handed one: use the ITaskbarList2::MarkFullscreenWindow API to explicitly tell Windows whether you're fullscreen or not, rather than relying on its heuristics. Once implemented the issue seemed to be 100% reliably fixed, though.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: