789417 - New appmenu button: Menu popups cover main part of dual menu buttons like "Options... | >" and other menus, making menu navigation difficult

Status: RESOLVED WORKSFORME

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Thomas D. (:thomas8)]

Attachment: Screenshot1: Menu popup covers main part of dual menu button

+++ This bug was initially created as a clone of Bug #784676 +++

Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0a1

STR:

New app menu button:
Hover over Options menu (or any dual/split menu)

Actual results:
- Main part of dual/split menu button is almost instantly covered by popup menu
- Practically no chance to click main part of button unless you rush it in less than a second

Expected results:

- popup menu should never cover dual menu buttons
- enable users to click the main part of dual buttons even if they need a second to think
- make behaviour consistent with other popups on non-dual buttons (the impression of jumping menus isn't nice, when you hover from non-dual button to dual button)

Comment 1

[Thomas D. (:thomas8)]

Attachment: Screenshot2: Correct menu popup on non-dual menus

This is the correct behaviour which we should have for dual menus, too.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #0)
> Created attachment 659176 [details]
> Screenshot1: Menu popup covers main part of dual menu button

More Actual Results:

- For the currently hovered dual menu, you might say this isn't too bad because we include the main part menu at the top of the hover menu, so it's still available in the same position (imo, the UX of this isn't good, though)
- What's really bad about this is that while the non-aligned (dual) popup is open, all other menus in the *same* column of the app button are also covered, e.g. File, New, Go, Message etc. all suddenly disappear just because you're hovering Options. It's all very flickery without need or benefit.

Comment 3

[Thomas D. (:thomas8)]

More Expected Results:

- to be clear, popups on dual(split) menu buttons should open to the (left) side of the dual menu, just like popups on non-dual menus (ux-consistency).

Comment 4

[Thomas D. (:thomas8)]

Blake, feedback?

imho it would be good to be less flickery/jumpy for dual menu buttons while hovering over appmenu's first level menuitems...

Comment 5

[Richard Marti (:Paenglab)]

Mike, you are the expert for this kind of things.

I think the problem is the menupopup has the .splitmenu-menu as it's anchorNode (this is the small part with the arrow in it). When the menu is on the right screen border, the popup open on the left of the .splitmenu-menu and covers the .splitmenu-menuitem.
Would it be possible to set the anchorNode to the splitmenu (the parent of all this items)?

If yes, would you be so kind to make a patch, because I don't know how to do this?

Comment 6

[Blake Winton (:bwinton) (:☕️)]

I don't think we really need my feedback here.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton) from comment #6)
> I don't think we really need my feedback here.

I think that means that Blake agrees with the intention of this bug as he did not file any objections.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

I also don't really have a problem with this bug - though I don't currently have the cycles to work on a fix.

Comment 9

[Tony Houghton]

This sounds like the problem I reported in bug 1223020, but for me there's a small delay before the submenu pops up. I wonder if Thomas D. has changed gtk-menu-popup-delay or some equivalent setting in TB? If so, I think this is the same bug and should be merged. Even if they're separate I think both could be avoided by simply repositioning the button on the left.

Comment 11

[Thomas D. (:thomas8)]

(In reply to Tony Houghton from comment #9)
> This sounds like the problem I reported in bug 1223020, but for me there's a
> small delay before the submenu pops up. I wonder if Thomas D. has changed
> gtk-menu-popup-delay or some equivalent setting in TB?

No, I haven't changed any settings. I also see small delay on Windows.

> If so, I think this
> is the same bug and should be merged.

Yes, I see exactly the same on Windows as in screencast of attachment 8685445 [details], so this isn't gtk-specific.

> Even if they're separate I think both
> could be avoided by simply repositioning the button on the left.

Yeah, but the question is: How important is that button for the general user?
Is it important enough to reposition the button *by default* to the left?
The most important everyday functions are probably available from toolbar, or context menus.
(Although I'm not the best person to judge because I'm always running with the traditional menubar).

Are you aware that you can actually easily move the button to the left yourself?
Right-click on (toolbar with) hamburger button, "customize...", and in that mode, just drag the hamburger button to the far left of the toolbar, then close customization palette. Done.
Does that help?

Comment 12

[Tony Houghton]

> Are you aware that you can actually easily move the button to the left
> yourself?
> Right-click on (toolbar with) hamburger button, "customize...", and in that
> mode, just drag the hamburger button to the far left of the toolbar, then
> close customization palette. Done.
> Does that help?

I should have at least thought of trying that! Yes, it does help, thanks.

Comment 13

[nithin[:lazybug]]

Hi , i would like to work on this bug

Comment 14

[Jia Yuan Lo]

I think Thunderbird should have similar menu design to Firefox

Having a Start Menu like at top right corner feels weird...
EDIT: OK thanks tony, moving menu to left corner feels much better...

Big app icon like menu from Firefox is welcomed but that's my opinion.
Make more sense as in Firefox like opening Help icon will open up a right sidebar menu that is close to the top right corner menu rather than Thunderbird's way of hover menus...

Thunderbird should do the same...

Comment 16

[Thomas D. (:thomas8)]

As duplicate bug 1296608 points out, there's a usability problem here which is bigger than described in my comment 0:

- hover app menu items with minimal delay as you're still thinking where to go (say you want file menu)
- hovering any split menu button almost instantly pops out big dropdown menus which cover much of the main menu list
- closing unwanted submenu requires extra precision clicks and isn't very intuitive (it popped up automatically from hovering but it doesn not easily go away by just hovering)

Comment 17

[Richard Marti (:Paenglab)]

No more needed with the new AppMenu.