1862415 - [Win 11 23H2] The label for Firefox fails to extend in the taskbar if Taskbar ungrouping feature is enabled

Status: RESOLVED WONTFIX

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

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: taskbar ungrouping weird behavior.gif

Found in

• Firefox 120.0b4

Affected versions

• Firefox 120.0b4
• Firefox 121.a1

Tested platforms

• Affected platforms: Windows 11 23H2 (v.22635.2552)

Preconditions

• Have "Combine taskbar buttons and hide labels" set to "Never" in Taskbar Personalization settings in Windows

Steps to reproduce

1. Launch Firefox with a new profile and then close it
2. Launch again Firefox with the same profile

Expected result

• The label for Firefox extends as expected in Windows taskbar

Actual result

• The label for Firefox fails to extend in the taskbar

Regression range

• No regression, new Windows 11 feature which affects Firefox

Additional notes

• The issue can be seen in the attachment
• The label will extend only if an additional new window is opened (see attachment)

Comment 1

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

:csasca, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 4

[Ray Kraesig [:rkraesig]]

Increasing severity due to multiple duplicates.

Comment 6

[Alice0775 White]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)

:csasca, if you think that's a regression, could you try to find a regression range using for example mozregression?

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e21a2a57d05dfe3c5ff8ba71131127fa781ffdd0&tochange=f026ead5dbfce9d6530429ac568ecc5544cc9b3b

And I confirmed that setting browser.startup.blankWindow to false fix this issue.

Comment 7

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

:florian, since you are the author of the regressor, bug 1447719, could you take a look?

For more information, please visit BugBot documentation.

Comment 8

[Ray Kraesig [:rkraesig]]

As :csasca notes, this is a new Windows 11 feature that doesn't properly handle Firefox's existing behavior — not a regression on our part, and certainly not from a patch that landed in Firefox almost three years before even preview versions of Windows 11 were made available.

Setting browser.startup.blankWindow to false may be a workaround, and will almost certainly provide useful steps towards a solution, but may not be the entirety of a solution on its own: see e.g. bug 1448423 and https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41592.

Comment 11

[Alice0775 White]

This bug also affected to PageInfo, Browser Toolbox window etc.
Curiously, the taskbar labels in the Select User Profile dialog (firefox.exe -p) and Library are working fine.

FWIW,
When this bug occurs, slightly dragging a task-button on the taskbar, then the label is displayed as expected.

Comment 12

[gserg.g]

This is not Firefox's fault, it's Microsoft's, but unfortunately Firefox would have to be the one to have to fix it.

Windows 11 originally had the ability to not group buttons on the taskbar removed from it. This caused a backlash and in October 2023 Microsoft added that ability back. Unfortunately, instead of just reusing the code that worked perfectly for 25 years, they "re-imagined" the feature. From now on, it dynamically chooses the width of the button for any started app, depending on how long the main window's caption text is.

This idea is not at all very thought through because the window caption can and does change all the time, and the taskbar only captures the very first window caption that it has when it has just appeared. If a millisecond later the window caption changes to something much longer, tough luck, the taskbar is not going to care. The only way to get it to recalculate the widths of the taskbar buttons is to launch another program, or to drag the existing taskbar buttons around a little bit.

This happens to all programs, not just Firefox.

I have a button on my keyboard that launches Calculator. I press that button a lot, for the sole purpose of triggering the recalculation of the widths of the taskbar buttons that are too short to show the current window captions.

Firefox apparently happens to have an empty main window caption the millisecond that window appears. This is what the taskbar grabs and calculates the button width based on it. Firefox then sets the caption to something else, but that is too late.
The evidence to support that hypothesis is that when there is slight delay in how fast Firefox starts, the taskbar allocates the button width correctly and shows the caption.

A workaround has to be to make sure that the main window has a long enough text at the very moment it appears, so that the taskbar can calculate the button's width based on it. This is what I believe Firefox needs to do. Just put a dummy window caption in the executable's dialog resources or something, does not matter what, just something long enough so that the taskbar always gives Firefox the maximum possible button width (which is the only width that should ever be used by the taskbar to begin with). The next millisecond you can dynamically change it to whatever you are dynamically changing it now.

Obviously, the proper fix would be to get Microsoft to stop calculating the button widths dynamically, but that is not going to happen.

Comment 13

[LP]

(In reply to gserg.g from comment #12)

This is not Firefox's fault, it's Microsoft's, but unfortunately Firefox would have to be the one to have to fix it.

Windows 11 originally had the ability to not group buttons on the taskbar removed from it. This caused a backlash and in October 2023 Microsoft added that ability back. Unfortunately, instead of just reusing the code that worked perfectly for 25 years, they "re-imagined" the feature. From now on, it dynamically chooses the width of the button for any started app, depending on how long the main window's caption text is.

This idea is not at all very thought through because the window caption can and does change all the time, and the taskbar only captures the very first window caption that it has when it has just appeared. If a millisecond later the window caption changes to something much longer, tough luck, the taskbar is not going to care. The only way to get it to recalculate the widths of the taskbar buttons is to launch another program, or to drag the existing taskbar buttons around a little bit.

This happens to all programs, not just Firefox.

I have a button on my keyboard that launches Calculator. I press that button a lot, for the sole purpose of triggering the recalculation of the widths of the taskbar buttons that are too short to show the current window captions.

Firefox apparently happens to have an empty main window caption the millisecond that window appears. This is what the taskbar grabs and calculates the button width based on it. Firefox then sets the caption to something else, but that is too late.
The evidence to support that hypothesis is that when there is slight delay in how fast Firefox starts, the taskbar allocates the button width correctly and shows the caption.

A workaround has to be to make sure that the main window has a long enough text at the very moment it appears, so that the taskbar can calculate the button's width based on it. This is what I believe Firefox needs to do. Just put a dummy window caption in the executable's dialog resources or something, does not matter what, just something long enough so that the taskbar always gives Firefox the maximum possible button width (which is the only width that should ever be used by the taskbar to begin with). The next millisecond you can dynamically change it to whatever you are dynamically changing it now.

Obviously, the proper fix would be to get Microsoft to stop calculating the button widths dynamically, but that is not going to happen.

How exactly this essay of ideas help in any way resolve the defect, or provide any significant insights in investigating it more? This is a bug tracker board, not a forum to complain about Microsoft 😊

The width issue you have mentioned numerous times, has been fixed by Microsoft in KB5035942 released in March 2024; I've never had the problem with label width since then.

Also, the fact that Microsoft did change this specific part of its taskbar label ungrouping implementation and Firefox never caught up, is by no means an excuse for Mozilla to not attempt a resolution. Actually, the mere fact that this defect has not been closed as "cancelled" or "wontfix" all this time, is a proof that the developers acknowledge this as an issue that has to be fixed, when it's prioritized internally.

In any case, I have fixed this by following the tips of previous comments in this and other similar bugs in the board, by tampering with FF's about:config.

Comment 14

[gserg.g]

(In reply to LP from comment #13)

How exactly this essay of ideas help in any way resolve the defect, or provide any significant insights in investigating it more? This is a bug tracker board, not a forum to complain about Microsoft 😊

It was the "put a dummy window caption in the executable's dialog resources or something, does not matter what, just something long enough so that the taskbar always gives Firefox the maximum possible button width" part :)

So I was not complaining about Microsoft, I was pointing out that while this is not Firefox'es fault, like rightfully mentioned in comment #8, it may still be Firefox that would need to adapt, because getting Microsoft to adapt is a non starter more often than not. And the reason I was pointing that out is that I was going to report this issue myself, found this existing entry, noticed there had been no activity for a month, and that no definitive direction for dealing with this problem had been selected.

If what I said was obvious enough to everyone and didn't need to be pointed out, then I apologize :)

Thank you for pointing out the update though, I appear to be missing it at the moment.

Comment 15

[Masatoshi Kimura [:emk]]

No longer reproducible with build 22631.3593 (probably 22631.3374 or later per comment #13). Can we close this bug?

Comment 16

[Ray Kraesig [:rkraesig]]

(In reply to gserg.g from comment #14)

If what I said was obvious enough to everyone and didn't need to be pointed out, then I apologize :)

You have no need to apologize. Your comment was thoughtful and informative, and while we might not have adopted the specific approach you suggested, your observations would definitely have helped us find a resolution it if Microsoft hadn't fixed it on their end. I can only assume the earlier respondent didn't actually read past the sixth word.

 

(In reply to Masatoshi Kimura [:emk] from comment #15)

No longer reproducible with build 22631.3593 (probably 22631.3374 or later per comment #13). Can we close this bug?

Confirmed. Closing as WONTFIX, since I don't think it makes sense to implement and ship a workaround applicable to only a small number of previous Windows sub-versions. (We can revisit this if it turns out a large number of users are stuck on affected versions of Windows.)