1717199 - Menu items not drawn correctly for chrome pages in a browser

Status: RESOLVED WONTFIX

(Core :: Widget, defect, P5)

Description

[Geoff Lankow (:darktrojan)]

Attachment: menus.png

Thunderbird's new address book is a chrome page loaded in a browser element. We have some XUL menus in the page. In Linux, <menuitem type="checkbox"> or <menuitem type="radio"> are drawn without their checkboxes or radios and <menuseparator> is not drawn at all. Other platforms work as expected.

In the screen shot attached, all of the items should have radio indicators beside them and there should be a separator after "Last, First". You can see this page for yourself in Thunderbird trunk or beta by setting the pref mail.addr_book.useNewAddressBook to true and opening the Address Book.

I suspect this has something to do with -moz-default-appearance.

Comment 1

[Geoff Lankow (:darktrojan)]

FWIW, I tried copying the one of the menus in question to Firefox's preferences page and the same problem applies there.

Comment 2

[Geoff Lankow (:darktrojan)]

<menu> is also affected.

Comment 3

[Geoff Lankow (:darktrojan)]

This might be a more appropriate component.

Messing around with this, I've noticed that I can set -moz-default-appearance to button or textfield, it's just the menu values that aren't working.

Comment 4

[Geoff Lankow (:darktrojan)]

Can we have somebody look at this? It's likely to become problematic given the plans we have for Thunderbird in the next six months.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Emilio, any idea here?
Thanks.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Geoff Lankow (:darktrojan) from comment #1)

FWIW, I tried copying the one of the menus in question to Firefox's preferences page and the same problem applies there.

Do you have a patch I could use to repro this on Firefox's preferences page, or alternatively some more concrete STR for Thunderbird? I don't see that address-book on Daily.

Comment 7

[Richard Marti (:Paenglab)]

Toggle mail.addr_book.useNewAddressBook and you use the new address book on TB 91 and newer.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

So this is not specific to Linux at all.

These pages are using the non-native theme (widget.non-native-theme.enabled, plus they're in a <browser type=content>), it just so happens that:

• On Windows 10 (by default, but not in HCM for example), it uses the proton non-native style (blocks like this).
• On macOS we enabled the native context menus, which cover these.

But this should also be an issue on windows 7/8, and win10 with HCM enabled.

There are various possible solutions:

• Don't use the non-native-theme on these pages (e.g., making them a chrome docshell, or special-casing them, though the later would be a bit unfortunate).
• Add support for these XUL values to the non-native theme (though that's pretty unfortunate, if you ask me, and quite a bit of work).
• Add non-native styles for these menuitems, like the ones windows 10 uses.

Comment 9

[Geoff Lankow (:darktrojan)]

<browser type=content>

That is something that had not occurred to me. I think we can just stop using a content browser for the Address Book without too many side-effects. There may be other bridges to cross in the future.

Comment 10

[Geoff Lankow (:darktrojan)]

This bug is also responsible for the separator in editMenuOverlay being invisible. I knew there was supposed to be one there, but now I know why it's not.

We'll go down the chrome browser route for now, but I might come back and look at fixing it with CSS.

Comment 11

[Alessandro Castellani [:aleca]]

Is this still an issue?

Comment 12

[Geoff Lankow (:darktrojan)]

It's still a bug but we don't care any more because we worked around it.