1492969 - Icon overlaps with radio/checkbox element on menu items on Linux

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[Rob Wu [:robwu]]

On Linux, when menu items of type radio/checkbox have an icon, the icon is shown above the checkbox/radio input.

For example, let's say that [ ] and ( ) are checkbox/radio elements, and X is an icon.
On macOS, menu items are rendered as follows:
[ ] X title 1
( ) title 2

Note that the first title is shifted to the right to make space for the icon.

On Linux, the same menu items are rendered as follows:
[X] title 1
( ) title 2

Note that the X and [ ] are rendered on top of each other, and that the titles always have the same alignment.


A variant of this issue was reported before in bug 1351418. That bug was patched by always moving checkbox menu items into a submenu, but that was before bug 1321544 introduced support for icons on submenu items.

Comment 1

[Rob Wu [:robwu]]

Attachment: menus-icons-and-extra.zip

1. Load extension, e.g. at about:debugging .
2. Right-click on the page and hover over the "Extension menu items" menu item at the bottom to show the submenu.

Expected (e.g. on macOS):
- The icons should clearly be seen.
- The radio/checkbox elements should clearly be shown on the menu items.

Actual (Linux):
- The radio/checkbox elements are obscured by the icon.

Comment 2

[Rob Wu [:robwu]]

Attachment: screenshot-linux.png

Screenshot taken on Linux. The icon (red cross) clearly overlaps with the radio/checkbox elements.

Comment 3

[Rob Wu [:robwu]]

PS. I accidentally exchanged the menu labels in the test case.
"[type] with icon" has no icon (contrary to what the menu label claims).
"[type]" has an icon.

This does not affect the validity of the test case though.

Comment 4

[Rob Wu [:robwu]]

Attachment: sidebar-menu-bug1492969.png

This issue is also seen at menu items in the View > Sidebar main menu for sidebar extensions.

STR:
1. Load sidebar extension, e.g. from bug 1493396.
2. Open the menu (maybe press Alt to show it), View > Sidebar.

Expected:
- The icon should not overlap with the checkbox.

Actual:
- An (auto-generated, default) icon overlaps with the checkbox before the extension.

Comment 5

[Rob Wu [:robwu]]

The behavior varies by platform (tested with Firefox 62):
- macOS: Icon prepended to menu label. This appearance might be buggy according to bug 1457937
- Linux: Icon overlaps with radio/checkbox (comment 2 / comment 4).
- Windows: Icon not shown if menu item has radio/checkbox (even if not checked).

Let's wait for a resolution on the desired behavior of menus (bug 1457937) before moving forwards with this bug.

Comment 6

[David Durst [:ddurst]]

NI shorlander on this (similar/related to bug 1457937). Note especially #c5 and the screenshots.

While icons in this context are rare, the collision is bad and not showing the icon seems strange; having a design aberration in this edge case makes sense to me, but... I am no designer.

Comment 7

[David Durst [:ddurst]]

Moving NI to emanuela because time.

Comment 8

[emanuela [ux]]

My recommendation is to make all panel with this structure:

Input & label

    [label]
--------------
[i] [label]

where [I] is an input (checkbox, radio).

Image & label

    [label]
--------------
    [i][label]

where [i] is an image (e.g. extension icon).

Input, Image & label

In the edge case we have both icon & input the alignment should be like this

    [label]
--------------
[I] [label] 
    [label]
--------------
[i] [I][label]

Please, let me know if this is something we are able to do!

Comment 9

[Rob Wu [:robwu]]

The requested end state is not implemented of any of our platforms. Notably on macOS, the icon order is "[I] [i][label]".

I need to investigate whether the requested appearance is technically feasible.

Comment 10

[emanuela [ux]]

(In reply to Rob Wu [:robwu] from comment #9)

The requested end state is not implemented of any of our platforms. Notably on macOS, the icon order is "[I] [i][label]".

Yes, we're making a conscious decision to establish our pattern, instead of following the platform one.

I need to investigate whether the requested appearance is technically feasible.

Yes, it makes sense. Thank you.

Comment 11

[Rob Wu [:robwu]]

Image & label

The "Image & label" case mainly applies to the History and Bookmarks menus (and to menu items for/from extensions).
The history and bookmarks menus never have an input box, so adding indentation is not quite useful there.
Moving the icon to the label position results in a visually misaligned menu label for all users (because the built-in Screenshots add-on adds a "Take a Screenshot" menu item):

[back] [forward] [refresh] [bookmark]
   Save Page As
   ...
   View Page Source
   View Page Info
   Inspect Element (Q)
   [i] Take a Screenshot

This looks like an unreasonable cost for solving the rare problem of icon+input case (this bug). I prefer to have well-aligned menu icons for the common case (input+label / icon+label), rather than breaking the common case to account for a rare case (icon+input+label).

Input, image & label

On macOS, the menus in the menubar are native and their appearance cannot be changed by us. macOS does support [input][icon][label], but the the icon is intentionally ignored to match the alleged lack of checkmark+icon support on other platforms.

Other non-native menus can be changed by us, but moving the position of the input ("image & label" case) is considerably more difficult than prepending an icon to the label.
Prepending the icon can be done with just changes to XUL and CSS (for Linux and macOS), whereas moving the position of the input also requires changes in platform-specific C++ for Linux, macOS and Windows.

Conclusion

Implementing macOS's approach on Windows and Linux takes the least efforts to fix this bug, with minimal risk of negatively impacting the appearance of menus with only icon or input. This is also the only approach that can be implemented in macOS's native menus. Summarized:

    [label]    Regular menu item
[I] [label]    Input (radio/checkbox)
[i] [label]    icon                           *
[I] [i][label] Input (radio/checkbox) + icon  *
                                              * different from comment 8 

Comment 12

[David Durst [:ddurst]]

Larger UX issue, then; back to UX for input.