View source for Changes to Fullscreen Unlock

<pre>
15:04 < humph> say you have canvas1 in fullscreen, and you request that canvas2 go into fullscreen, such that it doesn't cancel fullscreen overall
15:04 < humph> an event doesn't get fired, since fullscreen isn't lost
15:04 < humph> I'm trying to write a test around this, wondering how you'd handle it?
15:05 < cpearce> humph: ok, so I'm changing this behaviour in bug 704039 which I was going to land today...
15:05 < humph> I was thinking to poll for a change in the fullscreen element, but that sucks
15:05 < humph> aha
15:05 < firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=704039 nor, --, ---, chris, NEW, Make document.mozCancelFullScreen restore previous full-screen state
15:05 < humph> what is new behaviour?
15:05 < cpearce> you can only request full-screen from an element which is a subelement of the current full-screen element, and...
15:05 < humph> our mouselock stuff relies on your stuff, so this is good to know
15:06 < cpearce> document.cancelFullScreen() will revert full-screen to have the previously requesting full-screen element as the full-screen element.
15:06 < cpearce> so in your example above
15:06 < cpearce> canvas2 probably couldn't request full-scren
15:06 < cpearce> since (I don't think) a canvas can have a canvas element child.
15:06 < cpearce> and
15:06 < humph> right
15:06 < cpearce> we also dispatch a mozfullscreenchange event whenever the full-screen element changes, not when the document full-screen state changes
15:07 < humph> that's good
15:07 < cpearce> we've implemted this spec: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
15:07 < cpearce> so you can read that to understand our behaviour
15:07 < humph> thanks
15:07 < cpearce> we still kept our old names (moz*) tho.
</pre>