1809694 - Hidden taskbar does not show when Firefox is re-focused if firefox is the only visible window

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[Dan]

Attachment: 2023-01-11 18-03-45.mkv

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

Steps to reproduce:

1. Turn on 'Automatically hide taskbar' on Windows 11.
2. Open Firefox.
3. Minimize Firefox.
4. Re-focus Firefox either using the taskbar icon or alt-tab.
5. Try and show the taskbar with the mouse.

Actual results:

Nothing.

Expected results:

The taskbar is meant to appear at the bottom of the screen.

Comment 1

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

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.

Comment 2

[Ray Kraesig [:rkraesig]]

(This seems to be separate from bug 1806438 et al., unfortunately.)

Is this new behavior? If so, can you use mozregression to narrow down when it was introduced? Conversely, does this still happen on a current Nightly build of Firefox?

Can you collect some diagnostic logs?

1. Open about:logging.
2. Set the "New log modules" field to timestamp,Widget:5,TaskbarConcealer:5, and click the "Set Log Modules" button.
3. At the bottom, select "Logging to a file". Click "Set Log File".
4. Click "Start Logging".
5. Attempt to reproduce the bug.
6. Click "Stop Logging.
7. Attach the relevant file to a new comment here. (There may be multiple such files, but only the one with "main" in the name should be nonempty.)

Comment 3

[Dan]

Attachment: log.txt-main.8172.moz_log

Comment 4

[Dan]

(In reply to Ray Kraesig [:rkraesig] from comment #2)

(This seems to be separate from bug 1806438 et al., unfortunately.)

Is this new behavior? If so, can you use mozregression to narrow down when it was introduced? Conversely, does this still happen on a current Nightly build of Firefox?

Can you collect some diagnostic logs?

1. Open about:logging.
2. Set the "New log modules" field to timestamp,Widget:5,TaskbarConcealer:5, and click the "Set Log Modules" button.
3. At the bottom, select "Logging to a file". Click "Set Log File".
4. Click "Start Logging".
5. Attempt to reproduce the bug.
6. Click "Stop Logging.
7. Attach the relevant file to a new comment here. (There may be multiple such files, but only the one with "main" in the name should be nonempty.)

I went through mozregression and couldn't recreate the bug on any builds. It exists on freshly installed nightly though.
Attached the log as file log.txt-main.8172.moz_log.

Comment 5

[Ray Kraesig [:rkraesig]]

I went through mozregression and couldn't recreate the bug on any builds. It exists on freshly installed nightly though.

That's very interesting, since one of the builds it installed should have been the latest Nightly. If you start mozregression, but don't interact further with it, and instead then try to reproduce the bug in Firefox (Release or Nightly), does it still happen? How about without mozregression, but with a random Notepad instance open? Does it still happen when nothing else is running (not even OBS)?

Do you have multiple monitors attached to this system?

If you restart explorer.exe (Windows Explorer) in Task Manager, does it still occur? Does it occur immediately on system startup?

Attached the log as file log.txt-main.8172.moz_log.

This does seem to rule out the TaskbarConcealer; it's being invoked due to the focus change, but it's not confused into thinking the window is fullscreen.

Comment 6

[Dan]

That's very interesting, since one of the builds it installed should have been the latest Nightly. If you start mozregression, but don't interact further with it, and instead then try to reproduce the bug in Firefox (Release or Nightly), does it still happen? How about without mozregression, but with a random Notepad instance open? Does it still happen when nothing else is running (not even OBS)?

OK so I did a few more tests and found exactly when it happens.
If I have another window open, say Notepad, and it is not minimized, the bug doesn't occur and the windows taskkar shows everytime as expected.
But, if the application is minimized (or nothing else open at all), the taskbar won't show.

I've also noticed another sign when the bug is active; a a thin white highlight appears at the bottom of the window, here it's usually just a subtle dark grey.

Do you have multiple monitors attached to this system?

No, a single laptop monitor.

If you restart explorer.exe (Windows Explorer) in Task Manager, does it still occur? Does it occur immediately on system startup?

Pressing the windows key fixes it, as does just launching the task manager with Ctrl+Shift+Esc. I can recreate this immeditely on startup.

Comment 7

[Ray Kraesig [:rkraesig]]

Does it still happen if:

• ... there's another Firefox window open, but it's minimized?
• ... there's another Firefox window open, but it's maximized?
• ... there's another Firefox window up which is neither minimized nor maximixed?
• ... there are no other Firefox windows, but the Firefox window you use to repro it is not initially maximized (merely partially offscreen under the taskbar)?
• ... you try to repro the bug using a maximized-on-startup Paint instead of Firefox?

(In reply to Dan from comment #6)

OK so I did a few more tests and found exactly when it happens.
If I have another window open, say Notepad, and it is not minimized, the bug doesn't occur and the windows taskkar shows everytime as expected.
But, if the application is minimized (or nothing else open at all), the taskbar won't show.

That at least means it's similar to some other taskbar misbehaviors I've seen (which prompted most of the suggestions above). However, it also means you might be able to use mozregression simply by manually minimizing the mozregression window at the start of each test. Can you try that?

I've also noticed another sign when the bug is active; a a thin white highlight appears at the bottom of the window, here it's usually just a subtle dark grey.

That's expected, given the other behaviors. The subtle dark grey is the autohidden taskbar itself (you can change your taskbar color to see this; I have mine set to purple specifically to diagnose this sort of thing), while the white line is the undrawn nonclient area of the window that the taskbar is supposed to be hiding (ref bug 642851 and bug 1802721).

Comment 8

[Dan]

(In reply to Ray Kraesig [:rkraesig] from comment #7)

Does it still happen if:

• ... there's another Firefox window open, but it's minimized?

No

• ... there's another Firefox window open, but it's maximized?

No

• ... there's another Firefox window up which is neither minimized nor maximixed?

No

• ... there are no other Firefox windows, but the Firefox window you use to repro it is not initially maximized (merely partially offscreen under the taskbar)?

No

• ... you try to repro the bug using a maximized-on-startup Paint instead of Firefox?

No, MS Paint behaves as intended.

That at least means it's similar to some other taskbar misbehaviors I've seen (which prompted most of the suggestions above). However, it also means you might be able to use mozregression simply by manually minimizing the mozregression window at the start of each test. Can you try that?

Minimizing mozregression did in fact allow the bug to be triggered. It seems to be all over the place.

Comment 9

[Dan]

Attachment: Mozregression results

Mozregression results (2023-13-01)

Comment 10

[Ray Kraesig [:rkraesig]]

mozregression jumps all over the place, but only to minimize the number of tests. This looks like the bug is indeed localized to 2022-09-18/-19... but also looks like you've reversed "bad" and "good" in mozregression. Can you confirm that that's what happened?

That said, the only patch on autoland in that timeframe that looks like it even might have affected this is D157597. Setting the regression field appropriately.

Comment 11

[Mathew Hodson]

You put bug 1789823 in the wrong field. It should be in the Regressed By field.

Comment 12

[Dan]

(In reply to Ray Kraesig [:rkraesig] from comment #10)

mozregression jumps all over the place, but only to minimize the number of tests. This looks like the bug is indeed localized to 2022-09-18/-19... but also looks like you've reversed "bad" and "good" in mozregression. Can you confirm that that's what happened?

There is certainly a chance, and apologies if I got them the wrong way round! I pressed 'Good' when FF behaved as expected, and 'Bad' when the bug occured.

Comment 13

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

:emilio, since you are the author of the regressor, bug 1789823, could you take a look?

For more information, please visit auto_nag documentation.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

I can reproduce this. Indeed MS paint doesn't reproduce the issue... But notepad does, which is hilarious!

The issue can be reproduced even if I early return in TaskbarConcealerImpl::MarkAsHidingTaskbar, so I think we're hitting some sort of heuristic of the Windows taskbar code now that we weren't hitting before...

It's unclear to me how to easily work around this? We could call ::ShowWindow() again after restore I believe, and that should restore (no pun intended) the old behavior, but that feels like a massive hack... Ray, you're way more familiar with the Windows taskbar shenanigans than I am, does the above seem like a plausible theory?

Comment 15

[Ray Kraesig [:rkraesig]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)

I can reproduce this. Indeed MS paint doesn't reproduce the issue... But notepad does, which is hilarious!

That's amazing. I hadn't suggested Notepad because you can't start it maximized — or at least I couldn't convince it to do so — but I suppose that's not necessary. (I have not been able to repro on my Win11 box with any application, including Firefox.)

The issue can be reproduced even if I early return in TaskbarConcealerImpl::MarkAsHidingTaskbar, so I think we're hitting some sort of heuristic of the Windows taskbar code now that we weren't hitting before...

Not surprising, unfortunately: the heuristics used are explicitly undocumented, and are definitely different between Win7 and Win10. I would not be at all surprised to learn that they're different yet again in Win11, nor even that they've changed between Win11 releases.

That said, the fact that a WS_MAXIMIZE-styled window is ever detected as "fullscreen" is definitely a Microsoft-side bug, especially since you've gotten Notepad to do it.

It's unclear to me how to easily work around this? We could call ::ShowWindow() again after restore I believe, and that should restore (no pun intended) the old behavior, but that feels like a massive hack... Ray, you're way more familiar with the Windows taskbar shenanigans than I am, does the above seem like a plausible theory?

Unfortunately, thanks in part to those undocumented heuristics, everything dealing with the taskbar is necessarily a massive hack. It sounds plausible enough?

Another thing you might want to check is what happens if you set widget.windows.fullscreen_marking_workaround to 1, and specifically if you can still go fullscreen with that active. I've done some minimal testing on my Win11 box, and didn't suffer the consequences I noted here; it might be sufficient to change our default heuristic.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

(Funnily enough I can repro on my laptop but not on my desktop, sigh...)

Will send a feedback hub ticket.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

(In reply to Ray Kraesig [:rkraesig] from comment #15)

Another thing you might want to check is what happens if you set widget.windows.fullscreen_marking_workaround to 1, and specifically if you can still go fullscreen with that active. I've done some minimal testing on my Win11 box, and didn't suffer the consequences I noted here; it might be sufficient to change our default heuristic.

That doesn't seem to help unfortunately...

Comment 18

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

Set release status flags based on info from the regressing bug 1789823