Closed Bug 702295 Opened 10 years ago Closed 10 years ago

DOM Fullscreen interacts badly with Pandora


(Core :: DOM: Core & HTML, defect)

Windows 7
Not set



Tracking Status
firefox10 --- verified
firefox11 --- verified


(Reporter: khuey, Assigned: cpearce)



(Keywords: verified-aurora, verified-beta, Whiteboard: [qa!])


(1 file)


1. Open Pandora in a tab, start playing music.
2. Open
3. Click the full screen button

What happens:

Pandora stops playing audio, is now in a broken state.


Pandora keeps playing music.
Weird. Doesn't happen on transition to/from F11 full-screen mode.
I got a chance to test this morning and for me when doing the html5 demo full screen, Pandora stops for a couple of seconds, then resumes play.  Same for when exiting full screen demo, a pause of 2-3 seconds, then play resumes and the controls etc on Pandora are all functional. 


System, win7 x64, 8 gig RAM, HD3200 on-board video card, HWA all enabled.
This regressed for me between:

GOOD 2011-11-01-03-11-08
BAD  2011-11-02-03-10-56

Regression range is:

This includes the landings to implement :-moz-full-screen-ancestor...
I've done a bisection, and this is a regression from bug 685779; the landings to implement :-moz-full-screen-ancestor.
And yes, if we remove the style rules for :-moz-full-screen-ancestor from ua.css, pandora works as expected when we enter full-screen.
Which of those properties is doing it?
This one:

/* If there is a full-screen element that is not the root then
   we should hide the viewport scrollbar. */
*|*:root:-moz-full-screen-ancestor {
  overflow: hidden !important;
Oh, I missed that rule.  Yeah, that would do it: it's causing a reframe of the <window> element in the browser UI, I bet, which reframes all plug-ins.

Do we want to propagate the :-moz-full-screen-ancestor into the browser UI?
So right now we go up the GetParentDocument chain in the fullscreen code.

We should probably change that to check whether we're changing docshell type and if so stop?
Right, we still need to propagate full-screen state into the chrome doc (currently other code relies on that) so the easiest thing to do is to simply not apply :-moz-full-screen-ancestor to the chrome doc (we should still apply the other full-screen state).
On second thoughts, I think it makes more sense to change the rule, rather than making :-moz-full-screen-ancestor not apply to the chrome document's root. The chrome document's root *is* an ancestor of the full-screen element after all.
Assignee: nobody → chris
Attachment #575301 - Flags: review?(bzbarsky)
Comment on attachment 575301 [details] [diff] [review]
Patch: Don't apply overflow:hidden to full-screen-ancestor chrome roots

Attachment #575301 - Flags: review?(bzbarsky) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 575301 [details] [diff] [review]
Patch: Don't apply overflow:hidden to full-screen-ancestor chrome roots

It would be good to get this on Aurora because if stops entering DOM full-screen causing plugins in other tabs to re-initialize, which will for example kill music playing or farmville running in a plugin in a background tab.
Attachment #575301 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 704250
Comment on attachment 575301 [details] [diff] [review]
Patch: Don't apply overflow:hidden to full-screen-ancestor chrome roots

We're early enough in the aurora cycle to take this.
Attachment #575301 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [qa+]
Verified in the latest nightly, aurora, beta and 10.0.2 on Win7 following the steps in comment #0.
Whiteboard: [qa+] → [qa!]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.