WordPress.org

Make WordPress Core

#27582 closed defect (bug) (fixed)

MCE View: CPU spike when using [video] embed for an MP4 in Chrome

Reported by: jeremyfelt Owned by: wonderboymusic
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.9
Component: Media Keywords: has-patch commit
Focuses: javascript Cc:

Description

Chrome 33.0.1750.152, OSX 10.9.2

As of the bump from MediaElement 2.13.2 to 2.14.0 in [27811], the display of an embedded MP4 with [video] in MCE spikes processor usage to 100% and crashes the tab in Chrome.

If I revert back to 27810, the view works as expected. If I use MediaElement 2.13.2 with current trunk, the view also works as expected.

If I use the [playlist] shortcode, everything works beautifully in trunk with 2.14.0. This new media stuff is fantastic. :)

Safari 7.0.2 freezes as well, though I haven't tested it extensively.
Neither Opera or Firefox freeze, though both show only text - https://cloudup.com/c2A2VMbeDkG

Attachments (1)

27582.diff (15.8 KB) - added by wonderboymusic 12 months ago.

Download all attachments as: .zip

Change History (15)

comment:1 @jeremyfelt12 months ago

I think I've traced this to commit a7f67b718 in MediaElement.

This scenario puts while (lastControlPosition.top > 0) into an infinite loop.

Last edited 12 months ago by jeremyfelt (previous) (diff)

comment:2 @jeremyfelt12 months ago

It seems like the initial page load results in two MediaElement view requests.

In the first request, a negative rail width (-1896) is set and the position of the fullscreen button is detected relative to the top of the document. This results in a top position of something like 719.12345. This results in an endless loop as the position never changes.

If I detect this first request (based on its negative rail width?) and skip it by returning without completing setControlsSize, a second request is made. In this second request, the rail width is normal (312), the position of the fullscreen button is detected with a top position of 0, and everything works properly.

This same successful request is made when switching between Text and Visual.

comment:3 @nacin12 months ago

  • Milestone changed from Awaiting Review to 3.9
  • Severity changed from normal to blocker

comment:4 @wonderboymusic12 months ago

In 27853:

Revert mediaelement-and-player.min.js to a usable build that doesn't cause an infinite loop. Still 2.14.0, minus the offending pull request: https://github.com/johndyer/mediaelement/commit/a7f67b71800af1dd742162f1be3ffe401b72b1f9

Reported upstream. 2.14.0 is necessary for playing m4a files properly. 2.14.0 with the offending pull request is unusable in Chrome.

See #27582.

comment:5 @wonderboymusic12 months ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 27861:

MEjs has been fixed upstream: https://github.com/johndyer/mediaelement/commit/1a75559c9d9ada344fee7a6f5f08ccc1e4b0fbfa
No more infinite loop.

This restores MediaElement to a clean build: 2.14.0.

Fixes #27582.
Thanks to jeremyfelt for tracking this down.

comment:6 @johndyer12 months ago

Thanks guys. This fix has been labeled as MediaElement.js 2.14.1 so that it matches up in Wordpress and other non-Wordpress sites.

@wonderboymusic12 months ago

comment:7 @wonderboymusic12 months ago

  • Resolution fixed deleted
  • Severity changed from blocker to normal
  • Status changed from closed to reopened

There is another maintenance release related to this issue: 2.14.2. Patch attached. I studied the changes, all looks good.

comment:8 @wonderboymusic12 months ago

  • Keywords has-patch added

comment:9 @ircbot12 months ago

This ticket was mentioned in IRC in #wordpress-dev by wonderboymusic. View the logs.

comment:10 @ircbot12 months ago

This ticket was mentioned in IRC in #wordpress-dev by wonderboymusic. View the logs.

comment:11 @nacin12 months ago

  • Keywords commit added

Cleared by me. Waiting for azaozz.

comment:13 @azaozz12 months ago

Looks good. Don't forget to bump the version in script-loader on commit.

comment:14 @wonderboymusic12 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.