feat(NcActions): add opened and closed events to handle closing/opening end | fix(NcPopover): correctly wait for animation end in after-show/after-hide events

[skjnldsv]

NcAcions

Following #6065

The evets are after-hide and after-show, not apply-hide and apply-show
https://github.com/nextcloud/nextcloud-vue/blob/ae77137aee5097dcbe8cef6c53eb1ce3bc81c7ee/src/components/NcPopover/NcPopover.vue#L230-L237

NcPopover

The vue-floating lib does not properly compute how long it needs to wait to know the popup have been shown/hidden.
I investigated and it's only using requestAnimationFrame which in that case isn't enough to ensure its completion.
Because we have our own custom animation variables, we need to manually check for it ourselves.

Tested on Server with log entries to see the duration (we use --animation-quick which is 100ms for us)

Before	After

[skjnldsv]

Only renamed for consistency with the onClosed method name

[ShGKme]

Instead of reading a CSS variable and adding a new task with timeout, can we use a native event here?

this.getPopoverContentElement().addEventListener('transitionend', () => {
	this.$emit('after-show')
}, { once: true })

[skjnldsv]

Love it yeah! Didn't realized transitionend was an option

[susnux]

Feature not fix (new event)

[ShGKme]

Fix for NcPopover, feat for NcActions

[susnux]

but the fix in ncpopover is unrelated to the feature for NcActions.
So this is semantically a feature PR ;)

[skjnldsv]

Yeah, was missing 🤷

[ShGKme]

/backport to next

[susnux]

This will now run quite late.
after-show will already await the next tick and the focus trap, so the additional tick in onOpened will cause a 1 tick delay which seems to not be needed. Probably the nextTick in onOpened can be removed.

[skjnldsv]

I think it's best to stay consistent. I'd like to avoid to have three different timings to watch for.
Two are perfectly fine:

1. we start closing
2. we are sure everything is finished and closed/hidden

[susnux]

Not sure about the additional tick we now have, but in general makes sense

[skjnldsv]

Instead of reading a CSS variable and adding a new task with timeout, can we use a native event here?

this.getPopoverContentElement().addEventListener('transitionend', () => {
	this.$emit('after-show')
}, { once: true })

Was still testing this, let me push a followup if it works ⌛
I should have disabled auto merge, my bad

[ShGKme]

A bit renamed for change log generation

[skjnldsv]

@ShGKme tested addEventListener('transitionend' a bit, and it is slower than a simple setTimeout. Weirdly waiting much longer (50ms difference)

setTimeout	transitionend

[skjnldsv]

Doesn't matter, much cleaner anyway
#6687

[ShGKme]

@skjnldsv On my test:

afterHide | 10967
transitionstart | 10992
afterHide:setTimeout | 11072
transitionend | 11085

So it's 13ms longer, than timeout, but the animation might also have started later, than we think in the timeout