-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RNMobile] Initial support for VideoPress v5 #35637
Conversation
With this commit, the main Video block files have been duplicated. They will be iterated on in subsequent commits and serve the basis of the changes we'll make to support VideoPress v5.
The Video block's is refactored to fetch VideoPress metadata, therefore enabling support for v5.
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
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 appearing at the bottom of this PR are passing or skipped. Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
loop: toggleAttribute( 'loop' ), | ||
muted: toggleAttribute( 'muted' ), | ||
controls: toggleAttribute( 'controls' ), | ||
playsinline: toggleAttribute( 'playsinline' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, the changed capitalisation of playsinline
(previously playsInline
) is intended, it's necessary to fix a bug with that setting. (See this relevant web change for an example of a change to fix a similar bug.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered converting this to BEM CSS and also making some changes to the class function, but ultimately decided to keep aligning as much as possible with the video block's code, to hopefully make any future changes as smooth as possible. Interested to hear if others feel it'd be better to approach this differently, though!
// Private videos will open in the player for logged in users with the WordPress.com URL. | ||
// However, they'll still display blank in the editor. | ||
// TODO: We need to iterate so that private videos display as expected. | ||
return metadata.is_private |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the function here to determine the best URL for each case:
jetpack/projects/packages/videopress/src/client/lib/url/index.ts
Lines 174 to 180 in eaddb2f
export function getVideoUrlBasedOnPrivacy( guid: VideoGUID, isPrivate: boolean ) { | |
if ( isPrivate ) { | |
return `https://video.wordpress.com/v/${ guid }`; | |
} | |
return `https://videopress.com/v/${ guid }`; | |
} |
I went with this approach after being unsuccessful trying to get private videos to play in the editor on Android. I hope we can land this as a first iteration and fix the issues with private videos separately.
@SiobhyB I'm encountering a crash on the iOS app when uploading a video or adding a video from the media library. I could reproduce it with both iOS simulator and actual device. However, it only happens when using a local build, in the wordpress-mobile/WordPress-iOS#22602 (comment) can't be reproduced. I'm curious about what might be the difference and if it's an actual crash that users would encounter. I checked the same flow using ios-upload-video-crash.mp4Here's the stack trace:
|
@fluiddot, thank you for testing! I see the stack trace is very similar to the crash reported in wordpress-mobile/WordPress-iOS#20882, which leads back to a crash in |
The strings used in the block's settings have been tweaked to match the web, so that translations can be reused.
Addresses feedback here: #35637 (comment)
I tested replicating some of the scenarios from this comment:
I believe this may be coming from this logic: jetpack/projects/plugins/jetpack/extensions/blocks/videopress/edit.native.js Lines 369 to 377 in f1ae7fb
When the device goes offline, the upload is marked failed from the host apps, and the "Failed to Upload" jetpack/projects/plugins/jetpack/extensions/blocks/videopress/edit.native.js Lines 172 to 174 in f1ae7fb
Perhaps on line 375 we would need to upload the logic to |
I was able to reproduce this for Android only on this PR's prototype build pr20181-f72c15e and the current I was not able to reproduce this in the 24.3-rc-1 beta. I created wordpress-mobile/gutenberg-mobile#6667 to investigate further. I agree with Carlos and don't consider this a PR blocker as it exists in |
projects/plugins/jetpack/extensions/blocks/videopress/edit-common-settings.native.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @SiobhyB, I tested the recent changes and confirmed the blocking issues I shared in #35637 (review) are now solved 🎊 . However, I noticed a new one (Empty state when using source URL of VideoPress video
) that we might consider addressing in this PR. I'm hesitant about it because it might be a bit of an edge case, WDYT?
✅ Inconsistent UI when retrying a failed upload
Fixed in 1955fc1 !
🟡 Exceprt shows the VideoPress URL
It can still be reproduced as shared in #35637 (review), but it's not a blocker for this PR.
🟡 No transition on the upload progress bar
It can still be reproduced but will be addressed in a separate PR (#35637 (comment)).
❌ Empty state when using source URL of VideoPress video
By inserting the source of a VideoPress URL, I managed to create a Video block that contains the guid
attribute but without the id
. This is rendered properly on the web version, but not in native where it's displayed as empty.
Steps:
- Copy the following URL: https://videos.files.wordpress.com/qDiVCMnq/0e2809330-1-2.mp4. This URL was obtained by getting the download URL from the VideoPress player.
- Create a post in a Simple site.
- Add a Video block.
- Insert the copied URL.
- Observe that the video can be played within the editor.
- Save the post and open it again.
- Observe that the post is marked as dirty. In this step, the video URL changed to the regular VideoPress URL.
- Save the post and open it again.
- Observe that the block is in the empty state.
- Preview the post.
- Observe that the video can be played.
Simulator.Screen.Recording.-.iPhone.15.-.2024-02-23.at.17.05.04.mp4
I tested the same behavior in version 24.2 and I can't reproduce it, so this seems a regression. If we decide that this will be covered in a separate PR or marked as low-priority due to being an edge case, I'll be happy to approve the PR.
@fluiddot, thank you again for the thorough review! Regarding the outstanding issues: Inconsistent UI when retrying a failed uploadI applied a fix in 1955fc1, but would like to investigate more why it's necessary to manually reset the states here, though it isn't in the Video block. @derekblank, I'd love to chat more next weeks given your insights from the offline uploads project. 🙇♀️ Excerpts shows the VideoPress URLI'm currently working my way up the tree of PRs, and plan to address this one in the native PRs. Thanks for flagging! To Be Addressed SeparatelyI'll plan to address the following issues separately (listed in order or priority):
I'll also create issues to keep track of the following, though may not personally tackle these myself in the short-term:
Let me know if I'm missing anything here! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fluiddot, thank you again for the thorough review! Regarding the outstanding issues:
[...]
Let me know if I'm missing anything here!
You perfectly covered all the issues in #35637 (comment), thanks @SiobhyB 🙇 ! As we considered addressing them in separate PRs, I'll proceed with approving the PR. LGTM 🎊 !
Regarding the issues, I'll be happy to help out in spare time between projects, so we could create associated GitHub issues and share the work. WDYT?
Thank you @fluiddot! 🙌
That sounds great, thank you! I think I'll also defer the With that, I'll begin the merge domino shortly and create a mini project board to capture all of these issues. 🚀 |
To follow up, I've created this GitHub board to organise the pending tasks to further refine this block. Thanks again for all the help merging the initial version! 🙇♀️ |
Fixes:
Related PRs
Gutenberg
: RNMobile: Add new Video block capability WordPress/gutenberg#59144Gutenberg Mobile
: Initial support for VideoPress v5 wordpress-mobile/gutenberg-mobile#6634Android
: Initial support for VideoPress v5 wordpress-mobile/WordPress-Android#20181iOS
: Initial support for VideoPress v5 wordpress-mobile/WordPress-iOS#22602Proposed changes:
The same approach followed by Carlos in #29256 is used, except the changes apply to both platforms and a different end point is utilised. The main changes are:
edit
component for VideoPress.Other information:
Jetpack product discussion
N/A.
Does this pull request change what data or activity we track or use?
No, it does not.
Testing instructions:
Note, installable builds have been generated for both platforms and linked in the related PRs section for ease testing.
Testing environments:
The changes in this PR will affect WordPress.com users who use the video block in the app, and following environments will need to be tested to ensure everything works as expected:
Note, self-hosted sites (whether Jetpack-connected or not) should continue to use the core video block.
Verify fix for videos not displaying thumbnails when previewed/published and not playing in the browser when uploaded via the app
Verify fix for plays inline setting not saving
play inline
.play inline
.Verify improvement when working between the web and the app
Further test for regressions
As this PR introduces a fairly large change to the way video block's work for WordPress.com sites, it'd be ideal to also go through the video block test cases to ensure there are no regressions.