coreui / coreui-pro / 37763056958

96%

main: 94%

push

github

fix(util): wait for a transition whose start a busy main thread delayed (#1588)

`executeAfterTransition` settles on the element's `transitionend` or on a
timer as long as the transition, set when it is called. When the main thread
is busy right after that call, the transition starts only once the thread
frees up while the timer is already due, so callbacks such as `shown` ran on
an element that had not moved yet (measured in Chromium: opacity 0 at the
callback in 5 of 5 runs, a 150 ms fade behind a 220 ms block).

A timer that fires more than a frame late is now read as the sign of that
delay. In that case only, a transition the timer covers, under way at the
call and no longer than the timer or of the given `transitionProperty`, that
still runs is waited for until it finishes or is cancelled, at most as long
again and one more second. That wait runs its own callback instead of
dispatching a `transitionend`, so it cannot settle another wait on the same
element. A timer on time, a hidden document and no covered transition still
running all take the old path.

Tab's `complete` returns once the tab has been switched away from: a switch
before the pane faded in left two tabs selected, and the longer wait would
have opened the same window after a busy thread.

The bundles grow by 809 B (`coreui.bundle.js`), 774 B (`coreui.esm.js`) and
794 B (`coreui.js`), gzip -9 against v6-dev, mostly the JSDoc the unminified
builds keep; the minified ones grow by 195 to 215 B and stay under their
ceilings. The three broken ceilings go up by 0.75 kB.

7332 of 7903 branches covered (92.77%)

Branch coverage included in aggregate %.

24 of 24 new or added lines in 2 files covered. (100.0%)

12675 of 12970 relevant lines covered (97.73%)

1586.34 hits per line