741864 - Fullscreen exists unexpectedly without firing mozfullscreenchange

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[David Humphrey (:humph)]

Attachment: Testcase

It appears that fullscreen can suddenly, and unexpectedly, exit without firing mozfullscreenchange.  The following test case correctly enters fullscreen when the link is clicked, but then immediately exists, and the mozfullscreenchange event isn't dispatched a second time.  My console looks like this:

[13:17:15.629] file:///tmp/html.html
[13:17:15.632] mozfullscreenchange fired, document.mozFullScreenElement is [object HTMLDivElement] @ file:///tmp/html.html:18
[13:17:15.634] Entered fullscreen: mozFullScreenElement === elem @ file:///tmp/html.html:21

Comment 1

[David Humphrey (:humph)]

I should note that I'm on 10.6.8.  I haven't tested on 10.7 (or other platforms).

Comment 2

[Diogo Golovanevsky Monteiro [:diogogmt]]

I hit the same problem on Ubuntu 11.04 and Windows7

Comment 3

[David Humphrey (:humph)]

This feels like a regression to me.  I'm trying to figure out when it started.

Comment 4

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: backtrace

The weird part is that we're apparently firing pagehide, which doesn't make much sense. That's what triggers the call through to MakeFullScreen(false)

I can't seem to trigger this on http://pearce.org.nz/full-screen/ or https://developer.mozilla.org/samples/domref/fullscreen.html There's no mozfullscreenerror event fired either.

For the record, this isn't happening on 10.7 (though to test on 10.7, remove fullscreenbutton="true" from browser.xul). I wonder if it has anything to do with the fact that we basically create new native widgets everywhere except 10.7, where we explicitly hand off to the OS instead of going through nsBaseWidget::MakeFullScreen (I think that's a fact).

Comment 5

[David Humphrey (:humph)]

> I can't seem to trigger this on http://pearce.org.nz/full-screen/ or
> https://developer.mozilla.org/samples/domref/fullscreen.html There's no
> mozfullscreenerror event fired either.

Same for me--these both work as expected.

Comment 6

[David Humphrey (:humph)]

If I modify the testcase so it uses a button instead of a link, it works.  Using:

<a href="" id="linkFullScreen">Set FullScreen</a>

it's causing a reload to happen.  What *should* happen in this case?

<button onclick="goFullscreen();">Fullscreen</button>

Works.

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Ah, this makes sense now. I think it's the right behavior too.

href="" defaults to the same URL and will cause navigation to happen. href="#" will work here since it doesn't cause navigation. Or you can call e.preventDefault() from the click handler.

Comment 8

[David Humphrey (:humph)]

So the reload causes the document with the listeners to go away, which makes sense.  However, should we not expect the event to happen (and get caught in the console) as it goes away?  Does the reload not cause various "unload" type events to happen?  This is obviously an edge case, but since I'm neck deep in fullscreen/pointerlock edge cases at the moment, it would be good to decide how tests will work.

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to Paul O'Shannessy [:zpao] from comment #7)
> Ah, this makes sense now. I think it's the right behavior too.

Though that means we're not behaving correctly on Lion. Probably because we don't set mFullScreen synchronously (we wait for OS X to tell us the window is fullscreen), but the navigation happens meanwhile and we call MakeFullScreen(false) & mFullScreen is already false so we just bail. Soooo, legit bug regardless!

If we're in transition, we should track that we got a followup call and exit when we finish the transition. I don't think there's a cancel call we can make.


(In reply to David Humphrey (:humph) from comment #8)
> So the reload causes the document with the listeners to go away, which makes
> sense.  However, should we not expect the event to happen (and get caught in
> the console) as it goes away?  Does the reload not cause various "unload"
> type events to happen?  This is obviously an edge case, but since I'm neck
> deep in fullscreen/pointerlock edge cases at the moment, it would be good to
> decide how tests will work.

That's a good question... I don't see anything in the spec (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) but I'm betting Chris would be able to answer it better! A quick test shows document.mozFullScreen==false and mozFullScreenElement==null in the unload event.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Any navigation while in fullscreen mode (or while transitioning to fullscreen mode) should cause fullscreen mode to exit (or the transition to abort).

So I think the bug as filed is invalid, since the testcase "navigates", so we should be exiting fullscreen.

(In reply to Paul O'Shannessy [:zpao] from comment #9)
> (In reply to Paul O'Shannessy [:zpao] from comment #7)
> > Ah, this makes sense now. I think it's the right behavior too.
> 
> Though that means we're not behaving correctly on Lion.

So... You're saying that if script requests fullscreen and then immediately navigates, the new page retains fullscreen in Lion? Or is something else happening?


> (In reply to David Humphrey (:humph) from comment #8)
> > So the reload causes the document with the listeners to go away, which makes
> > sense.  However, should we not expect the event to happen (and get caught in
> > the console) as it goes away?  Does the reload not cause various "unload"
> > type events to happen?  This is obviously an edge case, but since I'm neck
> > deep in fullscreen/pointerlock edge cases at the moment, it would be good to
> > decide how tests will work.
> 
> That's a good question... I don't see anything in the spec
> (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) but I'm
> betting Chris would be able to answer it better! A quick test shows
> document.mozFullScreen==false and mozFullScreenElement==null in the unload
> event.

Because the mozfullscreenchange is being dispatched asynchronously, by the time we come around to firing it, the old document is not considered active, so the event is discarded.

Comment 11

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to Chris Pearce (:cpearce) from comment #10)
> So... You're saying that if script requests fullscreen and then immediately
> navigates, the new page retains fullscreen in Lion?

The window is still in fullscreen, but the page isn't. I filed bug 742178.

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.