Open app menu on hover

[jancborchardt]

Summary

The new app-menu currently requires a click to open which is an extra step, which many people complain about. Also its vertical clickable size does not extend to the height of the header bar, which makes it unnecessarily smaller and more difficult to click.

The clickable area is now extended to fit the height of the header (while the visual feedback continues looking nice like before). Also, the visual feedback is unified into one element.

And to make it quicker and easier to open the menu, @kra-mo brought up that a simple hover should do the trick (not focus though to not mess with accessibility). There is a short timeout before it opens, similar like how Amazon does on their "Sign in" and language menus in the header.

Additionally, there is a short timeout which catches clicks on the waffle menu / app icon + name so that people who are used to the previous behavior don’t accidentally immediately close the automatically opened menu.

As discussed with @kra-mo, also FYI @pringelmann so it doesn’t conflict with how you would do things, or your work in #60937

Before

Screencast.From.2026-07-01.16-00-29.webm

After

(Highlight looks like the corners are not rounded, but that’s cause of screencast compression)

Screencast.From.2026-07-01.15-55-09.webm

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[susnux]

The new app-menu currently requires a click to open which is an extra step, which many people complain about

Its not the click that people complain about.
Its the fact that you first need to open the menu, then search for the entry and then click it.

Before you moved the mouse up, during that move you could already look for the entry / remember it and steer the mouse directly to the entry.

TBH I think this would make the behavior even worse, for people not liking the waffle menu it will be the same as you still need to move the mouse to the trigger, open it and re-position to the entry.
But for everyone this adds more noise, one of the worst UI things is if suddenly elements pop up if you not intended to open them and this will haven quite often here by just moving the mouse.

[susnux]

Implementation is very complex and adds a lot of things while from the description of the feature a simple addition of the popoverTriggers to the NcPopover would be enough 👀

[blizzz]

not to hijack it, but what about a shortcut? #keyboardNavigation

[pringelmann]

Deployed to a preview link so we can get a feel for it (u: bob / p: bob)

I'd tend to agree with @susnux here: not sure if the hover interaction is really helping. But will reflect on it. If we do end up with a consensus to go this route I can help simplify the implementation.

[jancborchardt]

@susnux yeah, it’s just a draft to check out the behavior. :) And my wording was not precise, I meant that it could possibly alleviate part of the complaints, where the "2 clicks" is def mentioned.
Specific implementation can be of course adjusted, or done from scratch.

The idea to open on hover comes from @kra-mo as mentioned (and I agree it’s a nice idea) and in the prototype I can’t really see any drawbacks compared to just opening on click, cause as said:

• There’s a tiny timeout before it opens, so mousing outside the browser via the app menu doesn’t open it
• There’s another timeout when clicking it, so that if you expect needing to click it, it doesn’t directly close it again
• There’s a bit of timeout when closing, so when you move the mouse outside of it a very short time, the menu doesn’t immediately close, so you have more leeway.

@blizzz a keyboard shortcut can be something additional and is not conflicting with this. :) But keep in mind many normal people either only know basic keyboard shortcuts or none at all.

[susnux]

can’t really see any drawbacks compared to just opening on click

The target area of the element is pretty close to e.g. the in-app search or main navigation entry.

But especially the input field is located there, imagine moving the mouse to that input field, then activate it.
The take your hand from the mouse to type on the keyboard, now the mouse moved a few pixels up.
This will already open the waffle menu and hide the search input even if not intended.

Or another new complaint that will likely be raised is that just because you hovered it you now have to wait for it to close again if you wanted to access the in-app navigation instead.

---

At least from my experience with casual users those both examples will happen and they will raise such complaints.
(and i can understand them, as until now I personally never encountered any UI that opens things on hover that was helpful and not distracting (explicit vs implicit actions)).

But basically I just wanted to note that this will not solve the discussions around that new UI.