Make WordPress Core

Opened 2 years ago

Last modified 7 weeks ago

#25076 assigned defect (bug)

CSS issue with native video player and flash fallback on full screen

Reported by: leandroprz Owned by: wonderboymusic
Milestone: Future Release Priority: normal
Severity: minor Version: 3.6
Component: Media Keywords: needs-patch
Focuses: Cc:



I noticed there's a bug with the CSS and the new native video player introduced in v3.6.

This is how it looks when not using full screen:


And this is how it looks when using full screen:


It automatically changes the color of the bar.

This is the shortcode I'm using to show the video:

[video src="video.mp4" width="640" height="360" autoplay="true" loop="true"]

I tested this on a fresh WP 3.6 installation with Twenty Thirteen theme. This is the CSS:

.mejs-container, .mejs-embed, .mejs-embed body {
	background: #464646;

.mejs-controls .mejs-time-rail .mejs-time-loaded {
	background: #21759b;

.mejs-controls .mejs-time-rail .mejs-time-current {
	background: #d54e21;

.me-cannotplay {
	width: auto !important;

I also tested it on a post and on a page, happens the same on both.

Change History (12)

comment:1 @SergeyBiryukov2 years ago

  • Component changed from Embeds to Media

comment:2 @wonderboymusic20 months ago

  • Keywords needs-patch good-first-bug added
  • Milestone changed from Awaiting Review to 3.9

comment:3 follow-up: @spmlucas20 months ago

  • Keywords reporter-feedback added

I'm not seeing any difference between the embedded version and the full screen version (using trunk and 2014 theme). Am I just blind, or is this no longer an issue?

Embed: http://snag.gy/wWwoi.jpg
Full-screen: http://snag.gy/oKxbJ.jpg

comment:4 in reply to: ↑ 3 ; follow-up: @leandroprz20 months ago

Replying to spmlucas:

I'm not seeing any difference between the embedded version and the full screen version (using trunk and 2014 theme). Am I just blind, or is this no longer an issue?

Embed: http://snag.gy/wWwoi.jpg
Full-screen: http://snag.gy/oKxbJ.jpg

Are you sure you are testing it with Flash? I can still reproduce this bug on trunk v3.9 alpha and Twenty Fourteen theme.

Last edited 20 months ago by leandroprz (previous) (diff)

comment:5 in reply to: ↑ 4 @thomasplevy20 months ago

I can reproduce this issue but I don't believe this can be resolved via CSS as the flash fallback displays a fullscreen flash player.

I believe the actual .swf file is controlling the styling of the player, not CSS. I'm not tremendously well versed in Flash -- but I think that's the essential issue.

comment:6 @caseypatrickdriscoll20 months ago


I'm just getting started on WP Core and this is my first ticket. Here is what I have so far.

First off, is this even a WP issue? It seems to me that it is a bug for the mediaelement.js library, which should be fixed in their project and trickled down to us. https://github.com/johndyer/mediaelement

Otherwise, I'm able to reproduce the problem by uploading a flv file in 3.8.1

Here is a link with a gif of a mp4 and flv video, along with a screen cap of the full player html5 and flv players

Both embedded players seem to correctly display the green time-current (#24890d) over “white” time-loaded. Bizarrely that seems to be because the html5 player is used for both

Full screen however (as shown in the imgur link) the html5 player is still the correct green over white (second photo), but the flash player becomes an incorrect “white” over “blue” (third photo)

I believe these colors (white #efefef and blue #3CACC8) are created in the FlashMediaElement.as file on lines 153 and 154

_scrubBarColor = (params['scrubbarcolor'] != undefined) ? (String(params['scrubbarcolor'])) : "0xefefef";
_scrubLoadedColor = (params['scrubloadedcolor'] != undefined) ? (String(params['scrubloadedcolor'])) : "0x3CACC8";

I believe they are then compiled to the non-editable flashmediaelement.swf file which appears in /wp-includes/js/mediaelement/

At this point I’m not sure how to proceed, because of my unfamiliarity with Flash and ActionScript. My biggest concern would be that if we recompiled the file we would miss something important, which is why we should leave it to the mediaelement.js library to edit.

Last edited 19 months ago by SergeyBiryukov (previous) (diff)

comment:7 @ircbot20 months ago

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

comment:8 @caseypatrickdriscoll20 months ago

Actually, I just realized this may be a complete non issue.

It's the theme that controls the html5 player's color, so it will almost always be different from the flash player, which cannot be controlled by css.

Edit: sorta changed my mind on this on further review. The file wp-includes/js/mediaelement/wp-mediaelement.css does contain the four default color lines.

.mejs-container, .mejs-embed, .mejs-embed body {
  background: #464646;

.mejs-controls .mejs-time-rail .mejs-time-loaded {
  background: #21759b;

.mejs-controls .mejs-time-rail .mejs-time-current {
  background: #d54e21;

.me-cannotplay {
  width: auto !important;

These defaults are an awkward orange over blue and we should just change them to be white over blue.

If I were to fix this issue right now I would just change

d54e21 to efefef and
21759b to 3cacc8

to match the flash player's colors (white over blue).

Last edited 20 months ago by caseypatrickdriscoll (previous) (diff)

comment:9 @wonderboymusic19 months ago

  • Keywords reporter-feedback removed

Fullscreen mode in most browsers when MEjs is using the Flash plugin is not reading the CSS at all, it is using the base styles baked into the flash instance. I think this is unfortunate, but probably expected, since there is no way to pass styles into the ActionScript.

comment:10 @wonderboymusic19 months ago

  • Milestone changed from 3.9 to Future Release

There is possibly a way to pass pluginVars when initing a MediaElementPlayer, but we can look at this later

comment:11 follow-up: @nacin17 months ago

  • Owner set to wonderboymusic
  • Status changed from new to assigned

Assigning this to wonderboymusic for eventual review (and to remove it from the good-first-bugs report).

comment:12 in reply to: ↑ 11 @netweb7 weeks ago

  • Keywords good-first-bug removed

Replying to nacin:

.. and to remove it from the good-first-bugs report


Note: See TracTickets for help on using tickets.