feat(NcActionInput): allow to prevent open on hover

[raimund-schluessler]

☑️ Resolves

• Allow to prevent opening the datepicker and select components in NcActionInput on hover.

While working on https://github.com/nextcloud/tasks/pull/2427 I realized that opening the NcSelect in NcActionInput on hover is quite disturbing, as it is unexpected and in many cases also undesired. E.g. when clicking a NcActionButton below the NcActionInput, the open NcActionInput blocks the view. Also, the select is open by default if it is the first element in the NcActions menu. This also looks weird. Furthermore, all other usages of NcDateTimePicker and NcSelect do not open on hover.

This PR adds a prop openOnHover that allows to disable this behaviour. By default it is still enabled to not introduce a breaking change.

🖼️ Screenshots

🏚️ Before:

Bildschirmaufzeichnung vom 2024-01-01, 10-38-37.webm

🏡 After:

Bildschirmaufzeichnung vom 2024-01-01, 10-33-30.webm

[ShGKme]

What's your feedback regarding accessibility @JuliaKirschenheuter @ShGKme? I would imagine the fix is good, but just to be sure. :)

I'd say that should be the default and the only behavior.

It is especially not comfortable for people with mobility disabilities. A shaking hand, cerebral palsy or just a broken wrist. Or you a using a laptop in a car while driving on a bad road.

Example scenario. User:

1. Opens a menu
2. Moves the cursor to an input element
3. Starts typing or only want to start typing and leaves the mouse to use keyboard
4. Due to some mobility disability, the cursor is moved
5. Focus is lost, catch it again. If a user doesn't look at the screen while typing, they may even not notice that during the typing.

Also, changing focus on hover triggers more actions on the screen reader (it is pronounced). And it could be more complex cognitively.

Example scenario. User:

1. Opens a menu
2. Moves to the first item "Label text"
3. The label is read in loud: Label text
4. Focus moves automatically: Label text edit Entered text Label text Label text
5. Cursor moves on the input
6. Input id read again: Label text

Many things are pronounced. UI state changes just on hover. Focus moves unexpectedly (there was no interaction, no clicks, no keyboard).

---

From my personal user perspective, I also don't see the benefits of focusing on input elements or opening selects/pickers on mouse move. This is not an expected behavior from my user experience.

[raimund-schluessler]

@ShGKme I agree with your analysis. But what is the conclusion? Should we remove focusing by mouse completely then? This is something the NcActions component does, see here: https://github.com/nextcloud-libraries/nextcloud-vue/blob/2f0f4c44c4b38b03a3a67e085c45355d912fc90b/src/components/NcActions/NcActions.vue#L1088-L1110

Hovering over an action item, be it a button, input, link etc. focuses it, pressing enter then executes the action.

[ShGKme]

But what is the conclusion? Should we remove focusing by mouse completely then?

From my PoV - yes, focusing any input elements should be removed.

But we cannot just remove this method, because it is required to activate elements on hover...

And we cannot remove .focusable from input-s to save keyboard navigation with arrows...

[raimund-schluessler]

This sounds like we should not focus the input, but should also not not focus the input 🙈

Btw. Keyboard navigation with NcActionInput of type multiselect or date is anyway completely broken at the moment.

[ShGKme]

This sounds like we should not focus the input, but should also not not focus the input 🙈

Focus on keyboard navigation, not focus on mouse

Btw. Keyboard navigation with NcActionInput of type multiselect or date is anyway completely broken at the moment.

*crying*

Thanks for noticing, it should also be fixed...

[raimund-schluessler]

Maybe it’s good if as a first step we already get this in as it fixes a big part of the issue already? The not-focusing-on-hover can be a follow-up then? :)

That would be an option, probably. But it has the drawback that we would have to add a prop that we would need to remove with the proper fix (which might be acceptable, as implementing the proper fix would make the prop obsolete, hence, could justify to not release a major).

[jancborchardt]

@raimund-schluessler @ShGKme @skjnldsv that’s your decision then. :)