Closed Bug 2064534 Opened 7 days ago Closed 16 hours ago

154's fix for the auto-hiding taskbar isn't fixed when opening a private window

Categories

(Core :: Widget: Win32, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
156 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 156+
firefox156 --- fixed

People

(Reporter: Joey, Assigned: gstoll)

References

Details

Attachments

(2 files)

Bug 2064534 - set window taskbar concealment more consistently r=#win-reviewers!
48 bytes, text/x-phabricator-request
Details | Review
requested log
4.34 KB, text/plain
Details

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

Steps to reproduce:

Background: version 154.0's fix from the release notes: "Fixed an issue on Windows where an auto-hiding taskbar would not appear until the Firefox window had been minimized and restored after launch."

But using Ctrl + Shift + P for a private window still faces the same bug.

Thanks.

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

That was Bug 1957069 which I had high hopes for, and unless I've misunderstood the description it's not fixed for normal windows either. I've just updated to 154.0 64-bit on Win10 and am still seeing the exact same behaviour as before:

  • If I maximize the window by clicking on the maximize button in the top right, everything's fine
  • If I maximize the window by double-clicking elsewhere in the titlebar, the autohidden taskbar (placed on the left in my case) does not appear when moving the mouse to the screen edge
  • This is 100% consistent and reproducible

Using key shortcuts to restore/maximize (Win+DownArrow, Win+UpArrow) also gives me the taskbar-lost result, but I hadn't tried that before updating to 154.0.

gstoll may be able to help. :gstoll flagging this since it is mentioned in release notes and in case we need to adjust

Flags: needinfo?(gstoll)

Sorry for the trouble everyone - I haven’t been able to reproduce the original problem on my system so the fixes have been somewhat speculative.

:Joey - what version of Windows are you on? And am I correct that with a private window (and auto hiding taskbar) that the problem goes away if you minimize and then maximize the window?

Mike - If you minimize and then maximize the window, does the problem go away for that window? (ie does maximizing after that by double clicking the titlebar make the taskbar appear if you mouse over there?)

Flags: needinfo?(mike.capp)
Flags: needinfo?(joe_the_fp)
Flags: needinfo?(gstoll)

(In reply to Greg Stoll :gstoll from comment #4)

:Joey - what version of Windows are you on? And am I correct that with a private window (and auto hiding taskbar) that the problem goes away if you minimize and then maximize the window?

Hi!
I'm on Windows 10. And correct: minimize/maximize (or pressing the Start kb button twice) brings back the taskbar. Presently, this (for me) happens when opening a private session as I indicated.

The much older problem for normally starting Firefox seems to have been fixed, which I asked about almost a year ago on the forums: https://support.mozilla.org/en-US/questions/1536105, i.e. I've been aware of it for quite some time.

I hope that helps, and thanks!

Flags: needinfo?(joe_the_fp)

(In reply to Greg Stoll :gstoll from comment #4)

Mike - If you minimize and then maximize the window, does the problem go away for that window? (ie does maximizing after that by double clicking the titlebar make the taskbar appear if you mouse over there?)

There's no permanent "problem go away" for a given window; whether the taskbar appears or not depends 100% consistently on the method most recently used to maximize it.

As Joey said, pressing the Windows key twice also brings back correct taskbar behaviour, but only until the next maximize. And even when the taskbar is being well-behaved for the current window, a new window opened with either Ctrl-N or Ctrl-Shift-P or the burger menu always has the problem initially.

Flags: needinfo?(mike.capp)
Severity: -- → S3

Update:
The issue is now fully back (i.e. even an initial browser start is affected), which I'm guessing is related to the mitigation sent out for bug 2064411, so the apparent initial fix may have been a false positive due to the password prompt.

See Also: → 1957069
See Also: → 2065189

Mike - I suspect your issue is different than these, and I've filed bug 2065189 to look into that.

:Joey - Thanks for the information! I have an idea of something that might fix the problem for you; would you be able to try it out? If so, open this link, click on the "Artifacts and Debugging Tools" tab near the bottom, and click on the "build/target.zip". After this downloads, unzip it somewhere, and go to the firefox folder and run firefox.exe. Note that Microsoft Defender SmartScreen will say it "prevented an unrecognized app from starting" - to bypass this, click "More info" and then "Run anyway" (please only do this for .exe's you trust!)

Flags: needinfo?(joe_the_fp)

I think our previous attempt to fix this in bug 1957069 was calling
OnWindowMaximized() too early for windows that didn't adopt the
PreXULSkeletonUI. Now we wait to call it until the window is shown. We
also call it if we're turning on the custom titlebar, which we know is
when Windows has trouble figuring this out.

Assignee: nobody → gstoll
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

A colleague of mine was able to reproduce the problem and verified that this patch fixed the problem, but I'd still love to hear from more people!

(In reply to Greg Stoll :gstoll from comment #8)

Hi. I've just done that, and tested multiple times:

  • Initial start: no problem
  • Ctrl+N: no problem
  • Ctrl+Shift+P: problem persists

Hope that helps; happy to do more testing.

Flags: needinfo?(joe_the_fp)

I have left
widget.windows.fullscreen_marking_method=0

it is still only method of relayble fix this 99% time, defualt setting is alot less reliable.

Probably next time I really let this be default is when I do whole new profile, but with my limited test new profile dont fix anything still need the aboce changed to 0

Thanks :Joey! I have a new theory - with that build, can you set browser.privateWindowSeparation.enabled to false in about:config, then restart and see if that fixes the private window problem? (I'm wondering if the fact that private windows get their own AUMID is causing this)

Flags: needinfo?(joe_the_fp)

(In reply to Greg Stoll :gstoll from comment #13)

I've done that and ... it's gotten weirder, to the point that I had to rewrite this reply to make it is not confusing.

  • Initial start: no problem
  • Ctrl+N and Ctrl+Shift+P: the problem came back but wasn't consistent (initially I thought it limited to whether I've clicked on anything in the window or not, but that wasn't it).
  • I then removed the "Recommended stories" and home screen search bar (to match my usage), and now the problem with both Ctrl+N and Ctrl+Shift+P is fully and consistenty back.

I've tested at least a few dozen times to make sure, including fully closing and restarting Nightly. I also copied this reply into a notepad so I can close my Firefox session for the last few tests.

Flags: needinfo?(joe_the_fp)

...hmm, that is strange. This sounds like it might be some sort of race condition.

If you're able, here's a new build to try that might work around that. (same instructions as before)

If you're able, it would also be helpful to get a log with string "TaskbarConcealer:5". For this I think it would be helpful to launch normally (with a maximized window), then open a Private Window, then quit Firefox to avoid confusion.

Thanks again!

Flags: needinfo?(joe_the_fp)

Sure thing. I'll read up on logging right away.
Question: same as before, does that include the about:config change?

Flags: needinfo?(joe_the_fp) → needinfo?(gstoll)

Great! Here's a good reference (just use that string above instead of one of the presets)

I guess I'd be interested in the behavior with that pref set to true or false. For the log probably just getting it with that pref set to true (i.e. the default) will be good enough. Thanks!

Flags: needinfo?(gstoll)
Attached file requested log —

(In reply to Greg Stoll :gstoll from comment #15)

Silly me I thought I'd start logging then exit.
Anyway, I've done the test, and about:config was left to the default, but I did remove the Homepage stuff that I don't use (same as earlier).

My ISP's DNS resolver for some reason is refusing to connect to the profiler webpage, but I did export it to a file and I'll attach it here.

Not to bury the lede: both Ctrl+N and Ctrl+Shift+P failed.

Let me know if the log (above) helps or if you need anything else! Thanks.

Thanks! The log is helpful and I think shows that the approach I've been trying isn't going to work.

So let's try something else :-) Can you try this build and see what the behavior is?

If something doesn't work, a log would be very helpful again.

I'm also interested in the fullscreen behavior - I'm a bit worried this is going to regress bug 1965699.

Thanks again!

Flags: needinfo?(joe_the_fp)

(In reply to Greg Stoll :gstoll from comment #20)

This worked perfectly! No issues at all: the auto-hiding taskbar stays on top (I can tell from the 1px or so high sliver that remains visible) and is retrievable.

By full-screen do you mean F11? If yes, then the taskbar is neither on top nor retrievable by moving the cursor all the way down, which is the standard behavior (AFAIK) with any full-screen application, e.g. Sumatra PDF in full-screen mode.
If not that, I only use FF is maximized-window mode, and that's what I've been testing, but happy to try other stuff.

As I indicated in comment #5 it was something that's been around for a year now, so many thanks.

Flags: needinfo?(joe_the_fp)

Great! I'll put some code up for review - thanks a bunch for your help!

I can reproduce this issue on Windows 10 with Firefox 154.0, but in my case it does not seem to be related to maximizing or minimizing the window.

Firefox starts with the window already maximized (its previous state). Simply opening Firefox is enough for the auto-hidden Windows taskbar to stop appearing when I move the mouse pointer to the bottom edge of the screen.

A few observations:

  • Pressing Ctrl+Esc once makes the taskbar appear and seems to "unlock" it.
  • After doing that, the taskbar normally continues to appear correctly when moving the mouse to the screen edge.
  • If I open a new Firefox window, the same problem occurs again for that new window until I press Ctrl+Esc.
  • Setting widget.windows.fullscreen_marking_method from the default value 2 to 0 completely fixes the problem for me.

So, at least on my Windows 10 system, Firefox appears to mark each newly opened maximized window in a way that prevents the auto-hidden taskbar from being raised, until something such as Ctrl+Esc causes Windows to reset/re-evaluate that state.

One additional detail: this is not related to Private Browsing in my case.

I reproduce the issue with normal Firefox windows. I do not need to open a private window at all for the taskbar to become blocked.

So this appears to affect regular maximized Firefox windows as well, at least on Windows 10.

I can confirm everything said by Carlos Velasco above:

  • the issue has not been solved, despite the release notes of version 154 claiming the opposite;
  • the issue is not related to private mode, and affects normal mode as well.

Furthermore, I suspect that the following bugs are in fact this one in disguise:

https://hg.mozilla.org/mozilla-central/rev/b09bd67f5557

Status: ASSIGNED → RESOLVED
Closed: 16 hours ago
status-firefox156: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 156 Branch

Could you consider nominating this for a release note? (Process info)

Flags: needinfo?(gstoll)

:ColourGrey - thanks for the info! I'll take a look at those bugs, but they do sound like the same underlying issue.

The (hopefully!) fix for this is in the latest Nightly build - if anyone can confirm that the issue is fixed in that build, that would be helpful! (please make sure to reset the pref "widget.windows.fullscreen_marking_method" to its default value of 2)

Release Note Request (optional, but appreciated)
[Why is this notable]: (hopefully!) a fix for a longstanding issue on Windows
[Affects Firefox for Android]: no
[Suggested wording]: Fixed an issue on Windows where Firefox could block an auto-hiding taskbar from showing.
[Links (documentation, blog post, etc)]: n/a

relnote-firefox: --- → ?
Flags: needinfo?(gstoll)

Thanks, added to the Fx156 nightly release notes, please allow 30 minutes for the site to update.

relnote-firefox: ? → 156+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: