[RNMobile] Android player controls

[jhnstn]

Fixes wordpress-mobile/gutenberg-mobile#5646
Depends on WordPress/gutenberg#49663

Proposed changes:

The following apply to Android only

• Disables the player control
• Adds basic play, pause, and replay functionality.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

On Android

• Go to a post with an existing VideoPress block
• Notice the play button on the video cover
• Select the block
• Touch the video
• The video should start playing.
• The control icon should change to a pause icon and disappear after short duration (800ms)
• Touch the video before it ends
• The control icon should reappear and change back to the play icon
• Touch the video
• The video should start playing
• Allow the video to finish (Note: make sure looping is turned off in the block settings)
• Notice the replay icon is displayed
• Touch the video
• The video should start playing from the beginning and the pause button should flash

Uploading a new video

• Add an new VideoPress block and choose a video from device
• Notice the play button is not displayed while the video is being processed
• Notice the play button is displayed once the video loads (Note: these changes do not address upload cropping )

On iOS

• Verify that the player behaves correctly and is using the built-in player controls

[github-actions]

Are you an Automattician? You can now test your Pull Request on WordPress.com. On your sandbox, run

bin/jetpack-downloader test jetpack rnmobile/add-android-controls

to get started. More details: p9dueE-5Nn-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ⚠️ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

[jhnstn]

When I first started working on this, the Player was still a small component. It ballooned a bit more after I added the preview logic. Since the player controls are 1. Android only and 2. hopefully a temporary work around I opted to put as much of the logic into a separate component.

[fluiddot]

@jhnstn Heads up that I pushed this commit c4d0115 to fix syntax and linting issues I noticed when reviewing the code (there was also this CI job failing).

[fluiddot]

@jhnstn I tested the controls in an emulator and an actual device but the videos don't play when tapping on them. Have you experienced this?

android-vp-controls.mp4

[jhnstn]

@jhnstn I tested the controls in an emulator and an actual device but the videos don't play when tapping on them. Have you experienced this?

This was due to a merge issue. The ref forwarding got lost resolving a merge conflict.

I have noticed that there are cases where the video does not play but the audio does. At the moment I am stumped on trying to reproduce this consistently. If you log the events:

diff --git a/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js b/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
index 7ce181dcfe..005a66e44a 100644
--- a/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
+++ b/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
@@ -127,6 +127,7 @@ export default function Player( { isSelected, attributes } ) {
 	}, [ preview, isPlayerLoaded, isRequestingEmbedPreview, previewCheckAttempts ] );
 
 	const onSandboxMessage = useCallback( message => {
+		console.log( 'onSandboxMessage', message );
 		switch ( message.event ) {
 			case 'videopress_ready':
 				setIsPlayerReady( true );

You can see the videopress_timeupdate events firing from the embed player. And as mentioned the audio plays so I suspect the problem might be with the WebView.

[fluiddot]

I have noticed that there are cases where the video does not play but the audio does. At the moment I am stumped on trying to reproduce this consistently. If you log the events:

diff --git a/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js b/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
index 7ce181dcfe..005a66e44a 100644
--- a/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
+++ b/projects/packages/videopress/src/client/block-editor/blocks/video/components/player/index.native.js
@@ -127,6 +127,7 @@ export default function Player( { isSelected, attributes } ) {
 	}, [ preview, isPlayerLoaded, isRequestingEmbedPreview, previewCheckAttempts ] );
 
 	const onSandboxMessage = useCallback( message => {
+		console.log( 'onSandboxMessage', message );
 		switch ( message.event ) {
 			case 'videopress_ready':
 				setIsPlayerReady( true );

You can see the videopress_timeupdate events firing from the embed player. And as mentioned the audio plays so I suspect the problem might be with the WebView.

I couldn't reproduce this issue on a physical device (Samsung Galaxy S20 FE 5G - Android 13). But as mentioned internally (p1683110146012529/1682712389.595559-slack-C04LWMHSGLC) this might be easier to be reproduced on specific Android models. I tried emulating a Pixel device and managed to partially reproduce it. However, the video never completely stopped. What I mainly noticed is that the video took longer to load and had some eventual stuttering during the playing.

In any case, I found a blocker for this approach related to R-rated videos. Those videos prompt the user to enter the DOB, so we encounter the same issue we had with touch events not being passed to the WebView. The DOB request is controlled by the embedded player, so unless we disable it via the VideoPress URL params as we did with the autoplay, this approach won't cover that issue.

[jhnstn]

It seems this approach has too unstable, closing in favor of loading the video preview in a standalone WebView