[RNMobile] Prevent validation error when viewing VideoPress markup within app

[SiobhyB]

Partially fixes WordPress/gutenberg#30987

At the moment, blocks with VideoPress markup create a validation error within the app. This creates a problem as posts that contain videos (for sites with VideoPress enabled) are automatically converted to use VideoPress markup when saved on the web.

Related PRs

• gutenberg-mobile: Prevent validation error when viewing VideoPress markup within app wordpress-mobile/gutenberg-mobile#4899

Installable builds

• android: [TESTING ONLY] Prevent validation error when viewing VideoPress markup within app wordpress-mobile/WordPress-Android#16664
• iOS: [TESTING ONLY] Prevent validation error when viewing VideoPress markup within app wordpress-mobile/WordPress-iOS#18775

Changes proposed in this Pull Request:

• Currently, for the web, an editor.js file "intercepts" the video block to make some modifications when saved. With this PR, a native version of the editor.js file has been created to enable us to make our own native-specific modifications.
• The new file defines attributes and utilises VideoPress' current save.js file to prevent a validation error when viewing a block with VideoPress markup within the app.
• It's necessary to import the new file into Gutenberg Mobile via the changes in Prevent validation error when viewing VideoPress markup within app wordpress-mobile/gutenberg-mobile#4899.
• Note, this initial PR only introduces "bare bones" support for VideoPress within the app. It prevents the validation error and allows some edits to be made (including to the caption and core video settings). However, VideoPress previews are still not supported (a default thumbnail is shown) and some key features (such as resumable uploads and poster selection) are still missing. In addition, VideoPress uploads directly from the app are still unsupported. These missing features are known, but not going to be addressed with this specific PR.

Screenshots

Before	After

Jetpack product discussion

N/A

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

N/A

Testing instructions:

WordPress.com site

1. In the app
   1. Create/edit a post
   2. Add a video block
   3. Insert a video
   4. Save the post
2. In the web
   1. Open the post
   2. Observe that the HTML code is different when changing to code editor
   3. Save the post
3. In the app again
   1. Open the post
   2. Confirm that the video block displays without error, as shown in the above "after" screenshot

Self-hosted site without Jetpack

In addition to confirming that the original bug is address, we should also confirm that there are no regressions to the way the video block appears for sites hosted outside of WordPress.com and without Jetpack.

1. In the app
   1. Create/edit a post
   2. Add a video block
   3. Insert a video
   4. Save the post
2. In the web
   1. Open the post
   2. Observe that the HTML code remains the same
   3. Save the post
3. In the app again
   1. Open the post
   2. Confirm that the video block displays as before, there should be no changes to its appearance within the app

[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.

---

Jetpack plugin:

• Next scheduled release: July 5, 2022.
• Scheduled code freeze: June 28, 2022.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello SiobhyB! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D81711-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[jhnstn]

Looks good, nice work!

[SiobhyB]

Thank you, Jason! Marking this as ready for review by the Jetpack crew now. :)

Note for the crew, I don't have commit access for WP.com, so would be grateful if you could handle committing to WP.com for me too. 🙇‍♀️

[anomiex]

I'll trust the team review on this one and rubber-stamp it, since all this does is add a native file that we don't use ourselves.

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D81711-code, and deploy it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[anomiex]

r247543-wpcom

[mkevins]

Hi @SiobhyB 👋 😄 . Thank you for your work on this issue!

VideoPress uploads directly from the app are still unsupported. These missing features are known, but not going to be addressed with this specific PR.

Because of the way that the core/video block is being "overriden" by the VideoPress block implementation, does this mean that, more generally, video uploads are not supported from the app, for certain sites / site-types? I suspect this is the case, since the URLs provided by the server would be different (even if the markup generated by the app is compatible with the original core/video block) (e.g. what I believe is occurring in the user report described here). Do you have any insights about that?

[SiobhyB]

@mkevins, thank you for checking in and highlighting that issue!

I don't believe the changes from this specific PR have been released into the app yet. They're set to be including in the upcoming 1.80.0 release of Gutenberg Mobile and the current 1.79.0 release (i.e. the release available in the app's latest 20.3 version) only has Jetpack changes up to this commit from February.

The changes from this PR should only override the core/video block when VideoPress markup is detected, so it shouldn't impact the default markup that's created when a video is uploaded via the app. It'll only come into action when a video is saved on the web (which automatically converts the block to a VideoPress block, creating the issue described at WordPress/gutenberg#30987). It shouldn't impact any app uploads, and didn't in my testing, but I'd definitely welcome additional testing when it's available in the app's 20.4 release. 🙇‍♀️

For the user report you linked to: I'll spend a bit of time exploring that either today or tomorrow and reply with thoughts on that GitHub issue. Thank you so much again for highlighting! And please do let me know if I'm missing any specific issues with the code from this PR.

[mkevins]

@SiobhyB 👋 😃

It shouldn't impact any app uploads, and didn't in my testing, but I'd definitely welcome additional testing when it's available in the app's 20.4 release.

I didn't mean to suggest that this PR impacted the uploads, so my apologies for not making this more clear in my comment 😅 . Rather, I noticed that you mentioned that this PR doesn't address the upload scenario, so I was hoping you might have some more context about that. The issue I linked to (a different one than this PR partially solves) seems to be reproducible with some site types (non-atomic business, and possibly also premium sites, for example).

tl;dr of that issue is that when the user uploads from the mobile editor, the upload actually completes successfully (at least, the video makes it into the WordPress Media Library), but the remote src URL that ends up in the video block content returns a 403, leaving the video unplayable in the editor as well as the front-end. Weirdly, when the user adds the very same video by choosing it from the media library, a different URL ends up in the block content, and the video works both in the editor and the front-end.

When I found this PR, I saw that it mostly addresses a separate (related) issue: that the content generated on web is parsed as invalid (and possibly modified?) on mobile - seemingly an issue that has been around for a long time 😅 . My hope was that perhaps you might know more about the different way that URLs are handled in the VideoPress block vs. Video block - but no worries if not. Hopefully that clarifies things a bit?

[SiobhyB]

@mkevins, aha! My apologies for jumping to conclusions and misunderstanding your question. 🤦‍♀️ Thank you for clarifying. I've now read through both the user's ticket and the Slack thread where you discussed with HEs for context. I've attempted to outline the context for this PR and my thoughts on the user's issues further below, let me know if anything is unclear!

Context for this PR

The app doesn't support VideoPress at the moment. So, any video uploaded via the app should have a plain *.files.wordpress.com URL associated with it in the editor. This is true for any simple WordPress.com site, regardless of plan.

The web is different. Videos uploaded to WordPress.com on the web will have a VideoPress URL associated with them. The code in this file make some changes to the core video block as part of the upload/VideoPress support.

If a post containing a core video block is saved on the web and the site has VideoPress enabled (e.g. WordPress.com sites), the code in this file will automatically convert the code to use VideoPress, just as it would if you'd uploaded directly to the web. This is what was causing a validation error within the app, due to the lack of VideoPress support.

This PR prevents the in-app validation error but video uploads via the app still aren't in alignment with the web in terms of VideoPress support. Video uploads in the app will still be uploaded to the unmodified core video block using the plain *.files.wordpress.com URL. Does that make sense?

More details around this PR: p9ugOq-2W8-p2

The user's issue

I attempting to reproduce using a simple site with a Business plan, but the video thumbnail appeared as expected and I was able to play it directly from the editor. 🤔

Looking over the thread, I noticed that some of the videos appeared to be VideoPress videos. Do you know if those were uploaded via the app or the web?

[mkevins]

Hi @SiobhyB 👋 😃 , thank you for your detailed reply!

Context for this PR

The app doesn't support VideoPress at the moment. So, any video uploaded via the app should have a plain *.files.wordpress.com URL associated with it in the editor. This is true for any simple WordPress.com site, regardless of plan.

The web is different. Videos uploaded to WordPress.com on the web will have a VideoPress URL associated with them. The code in this file make some changes to the core video block as part of the upload/VideoPress support.

If a post containing a core video block is saved on the web and the site has VideoPress enabled (e.g. WordPress.com sites), the code in this file will automatically convert the code to use VideoPress, just as it would if you'd uploaded directly to the web. This is what was causing a validation error within the app, due to the lack of VideoPress support.

This PR prevents the in-app validation error but video uploads via the app still aren't in alignment with the web in terms of VideoPress support. Video uploads in the app will still be uploaded to the unmodified core video block using the plain *.files.wordpress.com URL. Does that make sense?

More details around this PR: p9ugOq-2W8-p2

Yes, this does make sense. Thanks for elaborating - this confirms my understanding of the PR changes. Also, thank you for that link!

The user's issue

I attempting to reproduce using a simple site with a Business plan, but the video thumbnail appeared as expected and I was able to play it directly from the editor. thinking

Looking over the thread, I noticed that some of the videos appeared to be VideoPress videos. Do you know if those were uploaded via the app or the web?

I'm pretty sure that these were uploaded via the mobile editor - but I have not been able to reproduce this myself, since my Business test site is an atomic test site. Afaik, this has been reproducible on a Business site without any plugins. Do you know whether the site you tried to reproduce this has any plugins (i.e. atomic?).

Another thing that was interesting in the thread where this was reproduced (p1657862661885529-slack-C03URUK5C), is that the URLs were different when inserted via the editor, depending on whether they were updated as part of upload completion, or if they were already uploaded and part of the Media Library.

When you mention *.files.wordpress.com, the part in the * wildcard is what is different. For example, it seems that the URL that results from upload completion looks like: https://videos.files.wordpress.com/..., while the URL that results from adding the same video from the Media Library (after it has already been uploaded) looks like: https://sitename.files.wordpress.com/.... To be even more specific, in case it helps, the ... in the former looks like: some-base64-id/some-file-name.mp4, and in the latter looks like: YYYY/MM/some-filename.mp4. Though, I expect that the difference in origin is more significant, especially since in the former case (after upload completion) the URL returns a 403 - Forbidden error.

I wonder, have you encountered URLs like this while exploring / testing this? I'm curious, because, if so, and you have not encountered the 403 error, perhaps there is some other issue at the root of that. If not, I think it's worth further investigating why the URLs can sometimes be different.