[Bug]: ApiVideoPlayer IFRAME steals focus for key presses when autoplay property is set to false.

[will-grange-inclusive]

Version

@api.video/[email protected]

Environment that reproduces the issue

Windows Chrome, but this appears to be common accross all browsers/devices tested so far.

Is it reproducible in the example application?

Yes

Reproduction steps

Clone and run the source code from the demo available here. See instructions in the README.md
https://bitbucket.org/inclusive/api-video-taking-focus/src/master/

The demo sets up the ApiVideoPlayer with autoplay=true and autoplay=false depending on what is passed in the URL to show different behavior.

Key presses are being made to unpause the video which pauses automatically again after 3 seconds by design. When autoplay=false, it can clearly be seen that the IFRAME steals focus and therefor the containing window cannot recieve keyDown or keyUp events. Clicking into the parent window again will refocus the parent and keypresses can be used again.

Scenario functioning correctly

1. Launch the demo with autoplay enabled (true)
2. Press a key
3. Press the video will play
4. Press a key
5. Press the video will play again

Scenario functioning incorrectly

1. Launch the demo with autoplay disabled (false)
2. Press a key
3. Press the video will play
4. No further key-presses can be received by the top level document as the IFRAME has focus

Expected result

Parent window can recieve keyUp and keyDown events, without the IFRAME taking focus when autoplay=false.

Actual result

No keyUp and keyDown events received because the IFRAME has focus after the first keypress.

Additional context

No response

Relevant logs output

No response

[will-grange-inclusive]

Screenshot from our bug demo where the IFRAME has stolen focus and no keypresses are being received:

[will-grange-inclusive]

Screenshot from our bug demo where autoplay is enabled and focus is not being stolen:

[will-grange-inclusive]

This is still a bug the the api.video player but a workaround can be a applied where the autoplay prop is set to true and the video is paused in response to the onReady callback. This will reproduce the effective autoplay=false behavior but the main window still has focus and keyUp/keyDown events etc can be received.

[will-grange-inclusive]

The above workaround (setting autoplay to true and pausing the video) did not help the situation on iPad Chrome and iPad Edge as this resulted in the audio not playing - see bug reported #22

Instead we have to detect that the window has blured, then take the focus back after a few miliseconds. We then simulate the keyUp even that we missed. The inputs/access then works as expected. Clearly this workaround is not ideal.

[olivierapivideo]

Hi @will-grange-inclusive
Thanks you for this detailed feedback. That is due to the accessibility features of the player that keeps the focus to capture key presses. We'll add an option to disable it. That will fix your issue. The updated version will be released today or tomorrow.

[olivierapivideo]

@will-grange-inclusive can you try with the new v1.1.0 version ?

Please note that there is one breaking change with this version. You'll now have to use

const videoRef = useRef<ApiVideoPlayerRef>(null)

instead of:

const videoRef = useRef<ApiVideoPlayer>(null)

To fix the focus issue, you can use the following parameter:

<ApiVideoPlayer
   hotKeys={false}
   // ...

We've also add a new customDomain parameter that you should use:

<ApiVideoPlayer
   customDomain='embed.xxxx.com' // replace with your domain
   // ...
   ```

[will-grange-inclusive]

@olivierapivideo - I've tested this on a branch of the bug demo app and with the hotKeys={false} property applied, that the key presses are no longer being swallowed by the IFRAME contents. We are mid testing (many videos * platforms * access methods to test), so not applying to our main code base just yet but closing this based on the demo app resolution.