Videos added/edited on the web don't load in mobile editor

[rachelmcr]

1. On the web, create a post and add a video block. (I added a video already uploaded to the site's media library.)
2. Save the draft.
3. In the app, open the draft post.

Expected: The video blocks will load (or at least the video block with no caption will load).
Actual: The error “Problem displaying block” appears instead for both blocks.

Saving the post in the app and trying to open it again on the web results in an error on that end: “This block contains unexpected or invalid content.”

I also confirmed that the same “Problem displaying block” error occurs if I add a video in the app, open the draft on the web and save it there, and then reopen the video in the app. There seems to be an issue between how Gutenberg web saves the video block markup and how Gutenberg mobile expects it to be.

Tested on iPhone XS, iOS 12.3.1, WPiOS 12.7.0.20190617

[rachelmcr]

This issue occurred on a WordPress.com Simple site with the Premium plan. @pinarol let me know that there's a known issue with how the video block code is handled for sites on that plan (internal ref: pafL3P-pg-p2), which is the likely cause for both problems I saw.

[marecar3]

Hi @rachelmcr,

I would split this problem into 2 parts.

1. The reason why we are showing: "Unsupported block type" is this: pafL3P-pg-p2 #comment-1712

@hypest is ⬆️agreement still ok for us?

2. Mobile shouldn't be changing the content of that block in that scenario (which results in invalid content on the web). This one needs to be examined and I will take a look at it.

cc: @frosty

[marecar3]

This issue is also reproducible on Android devices. I have found the root cause of the problem.
It seems that mobile apps are changing the <--wp:video... content.

[marecar3]

Hey @rachelmcr @frosty, just to let you know that it's a known issue and it doesn't have high priority
pafL3P-pg-p2 #comment-1720

[designsimply]

Re-tested and confirmed with 13.5-rc-1 that video blocks added using Calypso Gutenberg do not load in Gutenberg Mobile with error "Problem displaying block" and confirmed that the precursor block comment code is changed after viewing the post in the app—the guid and src attributes go missing.

On the web:

<!-- wp:video {"guid":"Kb3sKmpL","id":54,"src":"https://aboutmakingmoviesmovie.files.wordpress.com/2019/10/59372044362__e5d32d89-e607-49a8-94b3-03ed7a014063.mov"} -->

In the app:

<!-- wp:video {"id":54,"className":"wp-block-embed is-type-video is-provider-videopress"} -->

^{Tested with WPAndroid 13.5-rc-1 on Pixel 3 Android 10.}

^{Tested with Gutenberg Calypso on Chrome 77.0.3865.120 on macOS 10.14.6.}

[kcswong]

Updating to say we were contacted about this by a user in #2900144-zen

[chipsnyder]

Looking into this it appears that SimpleSites on a premium plan are creating video blocks with the following pattern which wraps the video URL in a div and was causing a block registration error in addition to removing the GUID parameter:

<!-- wp:video {"autoplay":true,"guid":"7IeP9E0R","id":34,"loop":true,"muted":true,"src":"https://chipsnyder.files.wordpress.com/2020/06/img_0029.mov"} -->
<figure class="wp-block-video wp-block-embed is-type-video is-provider-videopress"><div class="wp-block-embed__wrapper">
https://videopress.com/v/7IeP9E0R?autoPlay=true&amp;loop=true&amp;muted=true&amp;persistVolume=false&amp;preloadContent=metadata
</div></figure>
<!-- /wp:video -->

Where an atomic site I'm using produces this syntax which wraps the URL in a video tag:

<!-- wp:video {"autoplay":true,"id":608,"loop":false,"muted":false,"playsInline":false,"src":"https://testeisbardev.wpcomstaging.com/wp-content/uploads/2020/04/60686287497__6ff2dbfc-6c7f-4ae0-8e54-992daf76849a-1.mov"} -->
<figure class="wp-block-video"><video autoplay controls src="https://testeisbardev.wpcomstaging.com/wp-content/uploads/2020/04/60686287497__6ff2dbfc-6c7f-4ae0-8e54-992daf76849a-1.mov"></video></figure>
<!-- /wp:video -->

I'm currently working on revisiting the block registration to handle these cases.

[chipsnyder]

Describing the issue helped me better understand @marecar3 comment here:

The reason why we are showing: "Unsupported block type" is this: pafL3P-pg-p2 #comment-1712

I'll sync up with him to see if there are any options to prevent the apps from overwriting what the web has.

As for the issue here for people like me who may have overlooked it. This configuration results in a jetpack/vaultpress block instead of a core/video block even though the code in the editor appears the same. To add support for this type Gutenberg would need to add support for Jetpack blocks.

[chipsnyder]

After discussing some options with others it looks like support for this is being tracked by Automattic/jetpack#12358 and work is underway to better handle the case when the block fails validation WordPress/gutenberg#15674.

The work that's being done in the parser should help provide a better experience

[hypest]

After discussing some options with others

👋 @chipsnyder, can you expand on the options discussed, or link me to related convos? I'm thinking, now that we have the ability to separate .com from .org code, maybe we can address this by incorporating the "Jetpack" side block too.

[chipsnyder]

Hey @hypest. I think there are some internal documents that capture parts of these options but I'm failing to uncover a combined explanation.

1. Make some changes to apply the guid formatting to the generated block more details here: pafL3P-pg#comment-1719
2. Add support for jetpack/vaultpress
   • This seems like the best option now that we have started added Jetpack Support in GBM
   • If memory serves me correctly this is what was decided on because at the time we hadn't added Jetpack support to GBM yet but we were working on it.
3. Modify Jetpack to use a different registration for the block like jetpack/vaultpress instead of core/video
   • This seems like it will have a lot of rippling consequences.

[chipsnyder]

Ps. There is worked started that seems to be going down the path of (3) mentioned here however that work seems to have stalled. Here is the PR and Issue I'm referring to:

• VideoPress: Revisit block extension behavior Automattic/jetpack#12358
• Block API: Refactor the parser module in preparation for further work WordPress/gutenberg#15674

[hypest]

I wonder, now that we have the Unsupported Block Editor in place, perhaps we could enable it for the video block by somehow detecting the situation with the Calypso treatment of the video block? Pinging @guarani in case you have some thoughts on this since you've worked on the UBE in the past.

[guarani]

I wonder, now that we have the Unsupported Block Editor in place, perhaps we could enable it for the video block by somehow detecting the situation with the Calypso treatment of the video block? Pinging @guarani in case you have some thoughts on this since you've worked on the UBE in the past.

I did a quick test and was able to reproduce this issue. Looking at the UBE, it might work to allow users to edit these video blocks that have been edited on the web, but unless we also update the UI to assure users that the Video block is not "unsupported", this could lead to user confusion. So as-is, the UBE doesn't feel like a drop-in temporary solution, unless we modify it for this use case.

Is the alternative to add support for jetpack/vaultpress block?

[hypest]

Is the alternative to add support for jetpack/vaultpress block?

AFAIK, Jetpack isn't actually registrering a new block type, it's just overrides the core/video one. In those terms, we'd need to add support for the Jetpack Gutenberg extension and see how to to wrangle the whole flow (detecting when to use which version when adding a new block too). We could explore that but sounds messy.

That said, the judging from the movements in Automattic/jetpack#12358, looks like that ticket is now in a prioritized list (at the time I'm writing this comment anyway) so, perhaps work on revising that Jetpack implementation will resume soon.

[thabotswana]

We have a user reporting this issue here: 5375141-zen

• They can add their video to their media library, then insert it into a post, but they can't upload directly from the editor.
• We have been able to reproduce this by uploading a video to a Simple site.

[SiobhyB]

This was resolved in Automattic/jetpack#24548 and will be further improved with some upcoming work on the Video block.