1746499 - Fix sizing and styling of Windows 11 context menus in HCM (and perhaps also outside of HCM?)

Status: RESOLVED DUPLICATE of bug 1766470

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

Description

[Morgan Reschenberg [:morgan]]

Attachment: Context menu on downloads panel in HCM Black

STR:

0. Enabled windows HCM
1. Navigate to any web page, or part of firefox chrome
2. Open a context menu

Expected:
Context menus are styled using the HCM color palette, but are otherwise the same as non-HCM context menus

Actual:
Context menus use the HCM color palette and are formatted without padding between options or <hr>s, this reduces readability. <hr>'s are also cut off on the left side in dark themes

Comment 1

[Morgan Reschenberg [:morgan]]

Attachment: Context menu on downloads panel in HCM White

Comment 2

[Morgan Reschenberg [:morgan]]

Attachment: Context menu on downloads panel, no HCM

Comment 3

[:Gijs (he/him)]

This is the standard sizing of context menus on Windows 10 (and, judging by your screenshots, windows 11), based on information the OS gives us. It's not really any different from the sizing of the same menus both inside and outside of HCM on Win7 and Win8. (IIRC, on win7 glass, they are actually even smaller!)

We added additional padding and custom styling to the Windows 10 menus outside of HCM because folks felt the pre-existing stuff looked ugly and out-of-date and hard to use, so UX gave them a make-over. But that's all custom, win10(+)-specific styling. Menu styles on Windows are an almighty mess (cf. the different styles in notepad, the taskbar (it's even different between the active apps and the clock/notification area!), the desktop, MS Edge, ... the list is endless).

So we added custom styles, including both colours and sizing, and don't apply the custom styles for HCM because we want the user to have the HCM, native colours that Windows provides us with, and to do that we use native menu appearance that's provided via our widget code and the CSS appearance property. See e.g. https://searchfox.org/mozilla-central/rev/7d17fd1fe9f0005a2fb19e5d53da4741b06a98ba/toolkit/themes/windows/global/menu.css#28-33 and https://searchfox.org/mozilla-central/rev/7d17fd1fe9f0005a2fb19e5d53da4741b06a98ba/servo/components/style/gecko/media_features.rs#559-565 . I don't know if we can actually "just" set more padding without also overriding the appearance for the items, in which case we'd have to do a bunch more CSS and/or widget work to avoid losing the colours and other features of the menu.

We could decide to increase padding also in HCM on Win10, but I don't think the current state is any smaller than it is on both HCM and non-HCM on Windows 7 and Windows 8. I also believe that it will obey any change in OS font size, so users who want bigger text in their menus can get them. So I'm not sure it's an accessibility issue? WDYT, Morgan?

Comment 4

[Morgan Reschenberg [:morgan]]

(In reply to :Gijs (back Jan 4, 2022; he/him) from comment #3)

We added additional padding and custom styling to the Windows 10 menus outside of HCM because folks felt the pre-existing stuff looked ugly and out-of-date and hard to use, so UX gave them a make-over. But that's all custom, win10(+)-specific styling. Menu styles on Windows are an almighty mess (cf. the different styles in notepad, the taskbar (it's even different between the active apps and the clock/notification area!), the desktop, MS Edge, ... the list is endless).

Oof I didn't realise there was that much variation :o good to know! I was comparing them to the context menus in Edge and File Explorer, which have much more padding (like our non-HCM ones). I assumed those were "plain" native, but I guess not? Is the menu I'm seeing an (unstyled) native menu, or is it a XUL one? And if it's native, why doesn't it change between windows 10 and windows 11?

FWIW on Win 11, I'm getting very similar styling between context menus on the task bar, notification area, edge, file explorer, desktop, etc. all of which are different than ours.

We could decide to increase padding also in HCM on Win10, but I don't think the current state is any smaller than it is on both HCM and non-HCM on Windows 7 and Windows 8. I also believe that it will obey any change in OS font size, so users who want bigger text in their menus can get them. So I'm not sure it's an accessibility issue? WDYT, Morgan?

I verified the menu does respond to font scaling :)
I'm less concerned about the Windows 10 appearance on windows 10 machines, given that it matches (or matches some of) the native app context menu for that OS version. I'm more concerned about the menu's appearance on Windows 11, where native menus have more padding/readability than the Windows 10 menu we seem to be using.

Comment 5

[:Gijs (he/him)]

(In reply to Morgan Reschenberg [:morgan] from comment #4)

(In reply to :Gijs (back Jan 4, 2022; he/him) from comment #3)

We added additional padding and custom styling to the Windows 10 menus outside of HCM because folks felt the pre-existing stuff looked ugly and out-of-date and hard to use, so UX gave them a make-over. But that's all custom, win10(+)-specific styling. Menu styles on Windows are an almighty mess (cf. the different styles in notepad, the taskbar (it's even different between the active apps and the clock/notification area!), the desktop, MS Edge, ... the list is endless).

Oof I didn't realise there was that much variation :o good to know! I was comparing them to the context menus in Edge and File Explorer, which have much more padding (like our non-HCM ones). I assumed those were "plain" native, but I guess not?

Our menus or Edge's? Ours aren't "plain" native. I don't think Edge's are either. I can't speak to Win11 file explorer, as I haven't yet used Win11.

Is the menu I'm seeing an (unstyled) native menu, or is it a XUL one?

Firefox's menus are always XUL-based, but we can either use the CSS appearance stuff to rely on nsLookAndFeel for sizing and colours (which in turn uses win32 APIs to request what size/colour a native menu would be, and can also do "glass" surfaces on Win7 etc.), or "just" custom-style things with CSS. For non-HCM themes on Windows 10 and higher, we choose the second option. For HCM themes, we do the former.

And if it's native, why doesn't it change between windows 10 and windows 11?

We're relying on nsLookAndFeel, which relies on win32 APIs, and those APIs have been lying to us for, uh, a long time. I'm not really surprised they're still lying. It's why we're using custom styling outside of HCM because the results from the API are ... not great.

FWIW on Win 11, I'm getting very similar styling between context menus on the task bar, notification area, edge, file explorer, desktop, etc. all of which are different than ours.

Interesting! I wonder if on Win11 we'd want to match that style even outside of HCM...

I'm less concerned about the Windows 10 appearance on windows 10 machines, given that it matches (or matches some of) the native app context menu for that OS version. I'm more concerned about the menu's appearance on Windows 11, where native menus have more padding/readability than the Windows 10 menu we seem to be using.

Yep, that makes sense. I'll update the summary here for Windows 11 and move this to widget code where nsLookAndFeel updates would need to be made.

:gcp, do you (or someone else working on Win11 / widget code) have cycles to investigate the Win11 styling and if there's new APIs we should use or some way to convince the old APIs to give us the right values?

Comment 6

[Morgan Reschenberg [:morgan]]

(In reply to :Gijs (he/him) from comment #5)

(In reply to Morgan Reschenberg [:morgan] from comment #4)

Oof I didn't realise there was that much variation :o good to know! I was comparing them to the context menus in Edge and File Explorer, which have much more padding (like our non-HCM ones). I assumed those were "plain" native, but I guess not?

Our menus or Edge's? Ours aren't "plain" native. I don't think Edge's are either. I can't speak to Win11 file explorer, as I haven't yet used Win11.

I thought edge's were plain native since they look the same as the windows file explorer menus. Who knows! Hard to know what "plain" native menus would look like, I guess :D

Comment 7

[:Gijs (he/him)]

(In reply to Morgan Reschenberg [:morgan] from comment #6)

(In reply to :Gijs (he/him) from comment #5)

(In reply to Morgan Reschenberg [:morgan] from comment #4)

Oof I didn't realise there was that much variation :o good to know! I was comparing them to the context menus in Edge and File Explorer, which have much more padding (like our non-HCM ones). I assumed those were "plain" native, but I guess not?

Our menus or Edge's? Ours aren't "plain" native. I don't think Edge's are either. I can't speak to Win11 file explorer, as I haven't yet used Win11.

I thought edge's were plain native since they look the same as the windows file explorer menus. Who knows! Hard to know what "plain" native menus would look like, I guess :D

Well, on Windows 10 I see these menus in Edge vs. the file explorer: https://imgur.com/a/r4JWvVR . They're... pretty different? Colors are different, size is different, shadows are different, rounded edges vs straight ones, icons on one and hardly any icons (mostly for third-party apps!) on the other, etc.

I expect that either both are "native", just using different APIs, or that at least the Edge one is non-native (ISTM it'd make less sense for the file explorer one to be non-native... but like you say, hard to know!)

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Redirecting to spohl who is leading Widget quality efforts.

Comment 9

[Stephen A Pohl [:spohl]]

Thanks for the heads up. Added to the list of accessibility bugs to investigate/fix.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Probably not a S2
Reminder, S2 means: (Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist

And it seems to be part of the backlog now

Comment 11

[Dão Gottwald [:dao]]

Bug 1766470 may have fixed this. Morgan, can you confirm?

Comment 12

[Morgan Reschenberg [:morgan]]

This looks fixed to me :) screenshot attached

Thank you !

Comment 13

[Morgan Reschenberg [:morgan]]

Attachment: current behaviour