App menu open on hover

[jancborchardt]

Summary

Handle app menu just like some other websites do their navigation, like the https://github.com/ main page, and https://nextcloud.com/

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 👀

[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.

[jancborchardt]

Checked how the homepage of github.com does it (need to check in a private tab, they don’t use the same when logged in):

• Using the same timings now, 90/180ms instead of 150/300ms
• Added a (hover: hover) and (pointer: fine) pointer gate, so it only works with mouse pointers (doesn’t mess up on mobile) and doesn’t trigger when the window is not focused

But we can’t use the newer NcPopover version until we are on our Vue components v9.

[jancborchardt]

Also fixed the conflicts with master after the polishing merge

[kra-mo]

The timeout is good, I like it.

But also, this is probably something that should be done upstream for all NcHeaderMenus instead. If @jancborchardt agrees with that from the design side, @susnux what do you think?

[susnux]

But also, this is probably something that should be done upstream for all NcHeaderMenus instead.

I do not think this makes much sense, the app menu is somewhat unique in this regards as you open it basically every time and there are no elements next to it.
While the other elements are opened more or less never and are close to each other so hovering will trigger many false positives. Also e.g. assistent dialog should not open on hover as it blocks main content.

I think if we want to make elements consistent in the header the first important step would be to make the menus look and behave simlar.
e.g. compare notifications with contacts menu or account menu.

• notifications has blurry background and animations
• other menus do not

It seems notifications was somewhat customized, this likely needs to be reverted and instead moved to NcHeaderMenu to make it consistent?

[kra-mo]

@susnux fair.

Yeah, the bespoke animation of the notifications should be reverted now given nextcloud-libraries/nextcloud-vue#8770

and they should indeed be consistent in general.

[susnux]

We can still evaluate if adding the hover open in a later cycle makes sense, but for this lets not squeeze that in.