Changes to Fullscreen Unlock

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.