User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36 Steps to reproduce: Create a video element that opens in an overlay, then click that video element's fullscreen button. The basic HTML: <div class="video-overlay"> <div class="video-wrapper"> <video ...>...</video> </div><!-- .video-wrapper --> </div><!-- .video-overlay --> The basic CSS: /* position the overlay */ .video-overlay { position: fixed; top: 0; right: 0; bottom: 0; left: 0; } /* center the player horizontally and vertically when not in fullscreen */ .video-wrapper { position: absolute; top: 50%; left: 50%; -webkit-transform: translate(-50%, -50%); -ms-transform: translate(-50%, -50%); transform: translate(-50%, -50%); } Open the page in FF (I am using v31) and start playing the video, then click the fullscreen icon. Actual results: You can still hear the audio, but the video disappears. Expected results: The audio should continue, and the video should remain visible, but grow to fullscreen. If I remove the transform: translate(-50%, -50%); in the debugger, the video becomes visible again, so this seems to be an issue with the CSS transform / hardware acceleration.

WFM with this testcase. Could you attach your own testcase if you're able to reproduce the bug.

Loic: Sure, and actually, in creating the testcase I was able to refine the problem more specifically to only when *!important* is added to the parent element's CSS transform! Testcase: http://aarontgrogg.com/testing/firefox-test.html All of the CSS and JS is in the page, very simple stuff: - relevant HTML is a video element inside of a div - the div initially only has *transform: translate(0)* and works fine in fullscreen - clicking the link in the Instructions adds a class of "important" which changes the transform to *transform: translate(0)!important* - after that the video disappears in fullscreen Other than CSS to keep the video player inside the window, no other CSS/JS is in the page. Hope this helps more, an thanks for grabbing so quickly, Atg

Attaching testcase.

Thanks for the testcase.

I verified locally that this fixes the testcase from comment 3 (and doesn't break the controls in fullscreen mode or anything else AFAICT).

Comment on attachment 8476300 [details] [diff] [review] fix v1: use !important in layout/style/full-screen-override.css Review of attachment 8476300 [details] [diff] [review]: ----------------------------------------------------------------- Someone with more CSS knowledge should review this...

(I probably can add a mochitest that tests the computed style of the parent element, based on one of the fullscreen API mochitests from bug 545812...)

I'm updating the fix slightly to use the "initial" keyword instead of hardcoding the initial value of each of the properties in question, for simplicity & future-proofing. I verified locally that this still fixes the issue, and that the property-values that I'm replacing are indeed the initial values of these properties, according to property_database.js. (I'll post a mochitest tomorrow, and probably request review from cpearce on that part, since it'll be plugging into his existing test_fullscreen-api.html-based mochitest collection.)

Here's a mochitest for this (or rather, a new sub-mochitest that's driven by test_fullscreen-api.html). I verified locally that this test fails without the fix, and passes with the fix. I kicked off two Try runs to sanity-check that, too: Without the fix: https://tbpl.mozilla.org/?tree=Try&rev=50e61d6f3c8f With the fix: https://tbpl.mozilla.org/?tree=Try&rev=abb82a1649a8 (Specifically, the part that fails without the fix is the part where I test whether we can set these properties on the ancestor nodes of a full-screen element, using "!important" -- and that's what you'd expect to fail, based on this bug report.) cpearce, I'm tagging you for review, since you wrote test_fullscreen-api.html, which this plugs into. (If you'd rather, I can tag a style-system reviewer, though.)

Comment on attachment 8477633 [details] [diff] [review] part 2: mochitest (using "hg cp" from another mochitest-file, file_fullscreen-hidden.html) Forgot to mention -- I used "hg cp" to copy the mochitest boilerplate from another file in this directory (file_fullscreen-hidden.html). So, bugzilla's diff viewer will make it look like I'm editing an existing file, but really I'm editing a *new copy* of an existing file.

(Improved the documentation in the mochitest a bit.)

(In reply to Daniel Holbert [:dholbert] from comment #10) > I verified locally that this test fails without the fix, and passes with the > fix. I kicked off two Try runs to sanity-check that, too: > Without the fix: https://tbpl.mozilla.org/?tree=Try&rev=50e61d6f3c8f Sorry -- I verified locally that I saw TEST-UNEXPECTED-FAIL lines in the output, without the fix, but it turns out those were from me using the wrong "is()" function (just plain "is" instead of "opener.is"), and they didn't actually get treated as test failures, as shown in that (unexpectedly-green) Try run. Fixing.

OK, here's the mochitest with that fixed. (In this version, I've removed the SimpleTest JS/CSS imports, since this isn't a top-level mochitest & hence doesn't need those -- and it's confusing (to me at least) for this file to have its own separate best-not-to-be-used "is()" / "todo()" etc. functions provided by SimpleTest.js) Try run with just the test (expected to fail): https://tbpl.mozilla.org/?tree=Try&rev=40d4fd19d055 Try run with test & fix (expected to pass): https://tbpl.mozilla.org/?tree=Try&rev=86cdcb904353

Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/55d62d21a98d https://hg.mozilla.org/integration/mozilla-inbound/rev/38e52ef2e131

https://hg.mozilla.org/mozilla-central/rev/55d62d21a98d https://hg.mozilla.org/mozilla-central/rev/38e52ef2e131