1935560 - Firefox prevents a taskbar in Windows set to autohide from unhiding when maximized

Status: NEW

(Firefox :: Shell Integration, defect, P3)

Description

[Michael Chan]

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

Steps to reproduce:

No meaningful steps. Firefox has remembered previous setting of starting maximized. When starting Firefox maximized, I am unable to unhide the taskbar using the standard mouseover.

This did not occur in the previous 132 versions and does not appear to occur in any other application including Edge.

Actual results:

When Firefox is maximized, if the taskbar is set to autohide, it does not unhide unless unmaximizing and remaximizing or by forcing the start menu to display with the windows key.

Expected results:

I would expect to mouse over the bottom of the screen and the taskbar to unhide.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Nick Rishel [:nrishel]]

I wasn't able to reproduce.

:Michael could you upload a screen recording of what you're seeing so I verify I'm checking the right thing?

Comment 3

[Michael Chan]

(In reply to Nick Rishel [:nrishel] from comment #2)

I wasn't able to reproduce.

:Michael could you upload a screen recording of what you're seeing so I verify I'm checking the right thing?

https://drive.google.com/file/d/1CNicuaMR4lD-5HcxIGAluCKrSJ3Nvosn/view?usp=drive_link

Comment 4

[Nick Rishel [:nrishel]]

Confirmed, n.b. this behavior does not reproduce if Firefox is started into the profile selector.

Comment 5

[Nick Rishel [:nrishel]]

[Tracking Requested - why for this release]:

Comment 6

[Nick Rishel [:nrishel]]

:mchiorean I can reproduce this in release, beta, and a local nightly build. For some reason it wouldn't reproduce under moz-regression. Any ideas/something QA can help isolate?

Comment 7

[Michael Chan]

To update, this persists into the new update that I just had installed - v 133.0.3

Comment 8

[Monica Chiorean]

(In reply to Nick Rishel [:nrishel] from comment #6)

:mchiorean I can reproduce this in release, beta, and a local nightly build. For some reason it wouldn't reproduce under moz-regression. Any ideas/something QA can help isolate?

Hello Nick,
I could not use moz-regression either to reproduce but verified 133.0a1 nightly builds and it started reproducing with this build https://archive.mozilla.org/pub/firefox/nightly/2024/10/2024-10-16-21-44-37-mozilla-central/ previous nightly is working. Hope this helps.
Thank you.

Comment 9

[Michael Chan]

Updating as Firefox just updated

Issue still persists in new v 134.0

Comment 10

[Michael Chan]

Updating for the new Firefox update.

Issue still persists in v 134.0.1

Comment 11

[Michael Chan]

Updating

Issue still persists in v134.0.2

Comment 12

[Michael Chan]

Updating

Issue still persists in v135.0

Comment 13

[Michael Chan]

Issue still persists in 135.0.1

Comment 14

[sporocyst.tw]

Not sure if this helps. Firefox will be 2560x 1440 in size when launching in maximized mode on my 2K screen. After remaximizing, it become 2560x1438 in size. And it is this 2 pixel difference in height that allows taskbar to detect cursor hovering and unhide.
So if there is a mechanism that decides how big the window is when launching in maximized mode, it probably worth a look.

Comment 15

[Michael Chan]

(In reply to sporocyst.tw from comment #14)

Not sure if this helps. Firefox will be 2560x 1440 in size when launching in maximized mode on my 2K screen. After remaximizing, it become 2560x1438 in size. And it is this 2 pixel difference in height that allows taskbar to detect cursor hovering and unhide.
So if there is a mechanism that decides how big the window is when launching in maximized mode, it probably worth a look.

I can confirm that I am also seeing this behavior.

Also updating for the new version.

This bug still persists in v136.0.1

Comment 16

[Michael Chan]

Still persists in v136.0.2

Comment 17

[u767778]

Please remove "Since v133.0 (including v136.0.2), " from the title and change the Version field to Trunk.

Comment 18

[Michael Chan]

(In reply to dtsa583s0 from comment #17)

Please remove "Since v133.0"

Is there specifically a reason? I figured it was worth noting when the behavior began.

Comment 19

[Steve]

And now V137.0

Comment 20

[Steve]

And you don't have this defect in Thunderbird.

Comment 21

[Steve]

And it continues in 138.0b1

Comment 22

[Masatoshi Kimura [:emk]]

Regression range according to comment #8:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=11ab9645846ff996343f1c5bdb0c65165724a1b6&tochange=462f654f2467c66d27121759aea4cf0675920a4c

Comment 23

[Masatoshi Kimura [:emk]]

Maybe bug 1922250 is the regressor?

Comment 24

[Carlos Velasco]

Same problem here

Comment 25

[Michael Chan]

Updated to reflect problem persists in the new v138.0

Comment 26

[Michael Chan]

Persists in v139.0

Comment 27

[Michael Chan]

Still persists in 140.0.2

Comment 28

[Nick Rishel [:nrishel]]

We know how to reproduce the issue, so unless the issue is coincidentally fixed by another change there's no need to update the status. Please the the title and other tracking information as-is.

Marking good-next-bug to keep this on our radar as on onboarding bug.

Comment 29

[Alex L]

This bug should not be accepted, because of the existence of the windows key workaround which always and everywhere opens the start menu even in full screen. If they don't like the keyed workaround because they exclusively navigate by pointing device, then users should not have auto-hide turned on.
While 'Windows set to autohide from unhiding when maximized' may be true I am having the exact opposite issue on my dual monitor when the auto hiding task bar doesn't disappear when I go into fullscreen (arguably the most important time for a hidden taskbar). Curiously this only appears to affect my primary monitor.

Ideally: entering fullscreen should always call the shell taskbar hide function, and moving the cursor to the bottom most pixel row of the browser should call the shell taskbar unhide function in fullscreen.
But failing that ideal, a hidden taskbar is always a preferable failsafe because the windows key workaround exists.

Comment 30

[Michael Chan]

(In reply to Alex L from comment #29)

This bug should not be accepted, because of the existence of the windows key workaround which always and everywhere opens the start menu even in full screen. If they don't like the keyed workaround because they exclusively navigate by pointing device, then users should not have auto-hide turned on.
While 'Windows set to autohide from unhiding when maximized' may be true I am having the exact opposite issue on my dual monitor when the auto hiding task bar doesn't disappear when I go into fullscreen (arguably the most important time for a hidden taskbar). Curiously this only appears to affect my primary monitor.

Ideally: entering fullscreen should always call the shell taskbar hide function, and moving the cursor to the bottom most pixel row of the browser should call the shell taskbar unhide function in fullscreen.
But failing that ideal, a hidden taskbar is always a preferable failsafe because the windows key workaround exists.

This is the most absurd reasoning I've ever heard. If your logic holds true, why is it that no other application functions this way? You're arguing that only Firefox is performing as expected and literally every other application is bugged? 🤡

Comment 31

[Carlos Velasco]

Note: setting "widget.windows.fullscreen_marking_method" to 1 fixed the problem for me