Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Description • 12 years ago

The source of much of the orange in our pointer lock (and probably fullscreen) tests seems to be caused because we can dispatch the (moz)fullscreenchange event before the transition to fullscreen is complete.

We should only dispatch fullscreenchange once the transition is complete. I've been trying to get the spec changed (and it looks like it's going to happen).

	David Humphrey (:humph)
	Comment 1 • 12 years ago

I'm hoping this is going to fix pointer lock bugs 745047, 745009, 754451, 753323, 744909, 745056, 712225.

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 2 • 12 years ago

Let's hope so.

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 3 • 12 years ago

(In reply to David Humphrey (:humph) from comment #1)
> I'm hoping this is going to fix pointer lock bugs 745047, 745009, 754451,
> 753323, 744909, 745056, 712225.

I added code to work around this issue in our pointer lock and fullscreen mochitests, and it indeed stopped the majority of the orange problems in those tests.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 4 • 12 years ago

Did any necessary spec changes happen here?

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 5 • 12 years ago

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #4)
> Did any necessary spec changes happen here?

Yes. In the spec [1] for the requestFullscreen() and exitFullscreen() algorithms, the steps that dispatch "fullscreenchange" and update the fullscreen stacks are now performed by tasks that are queued after the step to "optionally perform some animation".

Arguably the spec could be more explicit that the "perform some animation" step is synchronous though.

http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 6 • 11 years ago

Are we spec compliant now?  (That is, is there anything more to do on this bug?)

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 7 • 11 years ago

This is not fixed, we still sometimes fire fullscreenchange before the transition is complete.

I've resorted to working around this bug in the mochitests by checking whether the window has reached the screen size like so:
http://mxr.mozilla.org/mozilla-central/source/content/html/content/test/file_fullscreen-utils.js?force=1

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 8 • 11 years ago

Here's where I got to last time, this doesn't work but it might give whomever follows up here some ideas.

	Alexander Vieth
	Comment 9 • 10 years ago

Requesting a status update for this ticket. Is there a plan to land a fix?

Note that Chromium also delivers the fullscreenchange event too early: https://code.google.com/p/chromium/issues/detail?id=396576

Link to the relevant spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440

	Chris Pearce [:cpearce (Not reading bugmail)] Reporter
	Comment 10 • 10 years ago

I don't have time to work on this unfortunately. Anyone else is welcome to take it.

	Xidorn Quan [:xidorn] UTC+11
	Comment 11 • 8 years ago

This should have been fixed by bug 1161802 (actually these two seems to be duplicate)