Update mediaelement.js to the latest version

[desrosj]

Follow up to #56319 (updating to the latest 4.x release).

The latest version of mediaelement, as of today, is ​5.0.5.

Version 5.0 made the player WCAG 2.1 compliant, but some of the changes required are breaking. It's possible this update can be merged into WordPress without issue, but this update needs to be fully tested, and there may be a developer note required to communicate action that needs to be taken by plugin and theme developers.

[desrosj]

The project's Migration Guide has specific changes to make and things to check when updating to version 5.x: ​https://github.com/mediaelement/mediaelement/blob/master/MIGRATION.md#migrating-from-4x-to-5x-version.

[desrosj]

Unintentionally removed the accessibility focus. Thanks for adding that, @joedolson!

Updated mediaelement.js to 5.0.5
Trac ticket: 56320

[westonruter]

The latest version is now ​v7.0.4. Note this release includes a ​performance fix.

[adamsilverstein]

Lets try to land this in 6.6, ideally we should commit this change soon so it gets as wide spread testing as possible.

[desrosj]

Replying to westonruter:

The latest version is now ​v7.0.4. Note this release includes a ​performance fix.

@coquardcyr I realize it's been nearly 2 years since you created the PR attached here, but would you be interested in refreshing it to include the current latest version for testing?

[coquardcyr]

Hey @desrosj,
Just to confirm we are talking about version 7.0.5 for the last version?

I updated the branch with that version.

[desrosj]

The PR is looking good. I'd like to see some manual testing to confirm there's no strangeness.

[adamsilverstein]

Testing Instructions

mediaelement.js is used to deliver a uniform video and audio playing experience to users. originally designed for the [video] and [audio] shortcodes (and maybe playlists?), I believe it is still used when inserting video or audio from the media library in the block editor.

1. create a new post and upload a video and audio file for testing.
2. embed the audio and video files.
3. view the post and test that the audio and video controls work correctly and that no errors are visible in the debugger console.
4. verify that mediaelement.js loaded with current version

Note: mediaelement was previously updated in https://core.trac.wordpress.org/ticket/39686 which might be useful to review for possible issues to look for.

[mukesh27]

@annezazu (Test Lead for 6.6) this ticket needs some manual testing. Could you please take a look when you have moment. Thanks!

[annezazu]

Flagged it for the core-test crew for now and will test early next week. I've been out much of this week but didn't want it to sit!

[adamsilverstein]

@coquardcyr - thanks for working on this.

I gave it a test and noticed some initial issues we need to resolve.

To test this I would up uploading an mp4 video file and an mp3 audio file to my page, and embedding them using shortcodes (instead of the block editor which inserts native video and audio html elements). I did this in the code editor view in Gutenberg (screenshot incoming).

The audio player loaded and worked as expected. The video player worked and loaded, however it seemed to missing part of its UI (see screenshot). One file seems to have failed to load "mejs-controls.svg" that is likely the issue.

[adamsilverstein]

I spent a little time trying to fix the loading issue and it will need some more work. The svg is now loaded in JS so it needs some changes to make that work correctly.

Likely we will need to punt this if we can't get the issues fixed by beta 1.

[adamsilverstein]

It should be possible to pass the correct path to the Javascript using a configuration variable, see ​this comment

Trac ticket:

[adamsilverstein]

I was able to fix the svg loading by adding the iconPath to the passed settings, see ​this commit

After this change, the icons for the video player loaded, however the main play button that is overlaid over the video was in the corner instead of the center of the video. In addition, I noted an error in the console indicating something went wrong. I will upload some screenshots.

[adamsilverstein]

Note that in my ​PR I also tried upgrading to the latest latest version - 7.0.5.

Since I'm still see unresolved display issues with the player, I'm going to punt this to 6.7 for now.

[adamsilverstein]

After discussing this during a performance bug scrub, we should consider another approach.

• Upgrading mediaelement is turning out to be a little trickier than just updating the library
• This is *only* used for legacy [audio] and [video] shortcodes, and really only as a shim for browsers that don't support video or audio natively
• All WordPress supported browsers now support native video and audio tags

In conclusion, I'd like to propose deprecating support for mediaelement.js and updating the shortcodes to use native HTML elements instead. Feedback welcome!

[joedolson]

We should conduct some up to date comparison testing between the accessibility of the native elements and MediaElement.js; last documentation I saw on ​native video accessibility was not favorable to the native video player, but that was five years ago, so it's probably not totally accurate anymore.

Updating shortcodes to use native HTML elements will probably visually change a lot of sites, since the HTML wrappers for mediaelement.js are common targets for style hooks. I'm not sure that's an easy path to take. Just a casual search on the .mejs-container wrapper ​shows significant use in themes.

[pbearne]

I like the idea of using HTML elements, but style changes might/will be an issue
we ship CSS to make the native look like the old MediaElement.js

[joemcgill]

Personally, I think it's ok to retain the MEJS library for shortcodes, but I don't think we need to prioritize upgrading the library, unless there is some real user benefit. We can also switch the shortcodes to using native with a documented way for sites that are relying on the MEJS library for styling purposes to retain its use.

If there are a11y issues with using native HTML video components, then it seems we would need to address the same issues for non-shortcode uses as well, and using the same implementation for shortcodes that we use for blocks would make this less complex to solve.

[adamsilverstein]

deprioritizing this work due to the challenge of upgrading and the plan to move to more modern solutions.