Don't return focus after close-after-click

[raimund-schluessler]

As alternative to #3028, I would like to propose a less complex solution for the Actions component focus-trap problem in #3021. When an Action has the close-after-click prop set, the focus is not returned to the initial element after closing. This enables programmatically focusing another element (e.g. an input element) after the Actions menu is closed. Checkout the example added.

In difference to #3028 it does not introduce a scoped slot, hence is not a breaking change, but just keeps the current behaviour intact, without changes to the app.
On the other hand, It is a bit less flexible, since the dev cannot configure whether the focus is returned or not at the moment. But if one really needs this option, it could be implemented by simply adding a prop for it.

[vinicius73]

It is a very good approach, thanks.
My only concern is it is a little implicit, and we can't avoid this behavior if we need.

[raimund-schluessler]

My only concern is it is a little implicit, and we can't avoid this behavior if we need.

That's true. But we can easily add a prop to the actionText mixin allowing to configure the behavior, i.e. hand over a focusTrap config and use it here
https://github.com/nextcloud/nextcloud-vue/blob/6cf563b41e86cba9481167e936a6dc40f4c602a2/src/mixins/actionText.js#L85

Maybe something for a follow-up if it turns out to be necessary? Or do you prefer to implement this immediately (can do so in the evening, if required)?

[vinicius73]

Maybe something for a follow-up if it turns out to be necessary? Or do you prefer to implement this immediately (can do so in the evening, if required)?

I'm suspect.

I am a big fan of composition over props...
But if it works well for your case, we can move forward.

[raimund-schluessler]

Maybe something for a follow-up if it turns out to be necessary? Or do you prefer to implement this immediately (can do so in the evening, if required)?

I'm suspect.

I am a big fan of composition over props... But if it works well for your case, we can move forward.

It definitely fixes the issue I am facing in the Tasks app. I would say we move forward with this solution and iterate further if we find it creates problems.

[skjnldsv]

Works, but I also noticed the keyboard nav is broken, when opening, the first item should be focused, it is not the case anymore.

1. Open the menu
2. Use arrow down to go to the second item
3. See it doesn't work

You have to tab once to get into the first item THEN you can use arrows keys agai,

[raimund-schluessler]

Works, but I also noticed the keyboard nav is broken, when opening, the first item should be focused, it is not the case anymore.

1. Open the menu

2. Use arrow down to go to the second item

3. See it doesn't work

You have to tab once to get into the first item THEN you can use arrows keys agai,

Indeed, but we have the same behavior on master, so not directly related to this PR. Could you open an issue, please?

[skjnldsv]

Yep, this is why I approved nonetheless :)

[PVince81]

👍

[skjnldsv]

@raimund-schluessler why do we have that in the documentation?
I feel this is not relevant with the ActionButton at all, no?
Feels like a corner case debug code leftover? 🤔 🙈

[raimund-schluessler]

I guess that depends, one could see it as an example how to focus the input field after clicking an action. But it's true, I mainly introduced it to check that focusing actually works.

[skjnldsv]

I figured, removed in #4724
I think the example is too broad to have its place here. The nextTick and focus is common usage I would say :)