Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#27582 closed defect (bug) (fixed)

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

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


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 -

Attachments (1)

27582.diff (15.8 KB) - added by wonderboymusic 10 years ago.

Download all attachments as: .zip

Change History (15)

#1 @jeremyfelt
10 years ago

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

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

Last edited 10 years ago by jeremyfelt (previous) (diff)

#2 @jeremyfelt
10 years 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.

#3 @nacin
10 years ago

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

#4 @wonderboymusic
10 years 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:

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.

#5 @wonderboymusic
10 years ago

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

In 27861:

MEjs has been fixed upstream:
No more infinite loop.

This restores MediaElement to a clean build: 2.14.0.

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

#6 @johndyer
10 years 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.

#7 @wonderboymusic
10 years 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.

#8 @wonderboymusic
10 years ago

  • Keywords has-patch added

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

10 years ago

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

10 years ago

#11 @nacin
10 years ago

  • Keywords commit added

Cleared by me. Waiting for azaozz.

#13 @azaozz
10 years ago

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

#14 @wonderboymusic
10 years ago

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