1229757 - Video progress bar and fullscreen control missing

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Marco Castelluccio [:marco]]

Attachment: Firefox

This is on a Nexus 5, see the screenshots to see the difference between Chrome and Firefox.

Comment 1

[Marco Castelluccio [:marco]]

Attachment: Chrome

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

I wonder if the site is providing it's own video controls, and for some reason is not able to provide the other controls on Firefox.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

I see a progress bar using Firefox for Android 46a1

Comment 4

[Marco Castelluccio [:marco]]

I'm still not seeing them in Firefox 47. The result is the same as the screenshots I provided in comment 0 and comment 1.

Comment 5

[Marco Castelluccio [:marco]]

CCing hallvors, since he's been working on Brightcove-related stuff.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

It's a CSS/flexbox issue. Removing -moz-box from this style fixes the problem:

.bc-player-d0609fa6-97b1-4605-b1d9-bf49a18766e1_default.vjs-has-started .vjs-control-bar,.bc-player-d0609fa6-97b1-4605-b1d9-bf49a18766e1_default.vjs-mouse .vjs-control-bar {
	display:-webkit-box;
	display:-moz-box;
	display:-ms-flexbox;
	display:-webkit-flex
}

I don't know exactly why, or what styling the -moz-box statement interacts so badly with. Karl might know more, or Daniel Holbert.

Comment 7

[Daniel Holbert [:dholbert]]

I get EXPECTED RESULTS here (the progress bar + fullscreen controls are visible, once the video starts playing), in Firefox Nightly on Android.

But, I can make it give me ACTUAL RESULTS if I disable the pref layout.css.prefixes.webkit (which makes Nightly behave like Release, in how it interprets Comment 6's style)

So: I think this is fixed by our webkit unprefixing effort.

(In reply to Hallvord R. M. Steen [:hallvors] from comment #6)
> Removing -moz-box from this style fixes the
> problem:
[...]
> I don't know exactly why, or what styling the -moz-box statement interacts
> so badly with.

It looks like they're expecting "-moz-box" to behave like "-webkit-box", which is not a valid assumption. -moz-box is not really useful for actual web content in HTML, IMO.  I guess things work decently if this element ends up "display:block", though -- that's what's presumably happening for hallvors when he disables that declaration in comment 6.

If we wanted to do any evang here, it'd be to ask the developers to include "display: flex" at the bottom of that style rule (as the unprefixed version of "-ms-flexbox"/"-webkit-flex") -- that would give them modern flexbox as the default behavior, for browsers that support it.

But in the meantime, this seems to Just Work with layout.css.prefixes.webkit=true, which means this is FIXED in Nightly & Developer Edition, and it'll be fixed for release users as well once bug 1259345 is able to land (once we've fixed all known regressions from webkit unprefixing and can let it ride the trains to release builds).

--> Marking this as FIXED by bug 1213126, with an additional dependency on bug 1259345.

(Please let me know if anyone's results are different than mine, though.)

Comment 8

[Marco Castelluccio [:marco]]

Fixing dependency per https://bugzilla.mozilla.org/show_bug.cgi?id=1171872#c10.

This bug and bug 1171872 are really similar (bug 1171872 was filed for controls missing in full screen mode, at that time controls were not missing in normal mode; this bug was filed later on for controls missing in general).