- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 12 May 2011 14:26:17 -0400
On 5/12/11 1:16 PM, Jer Noble wrote: > > On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote: > >> On 5/12/11 4:12 AM, Jer Noble wrote: >>> - Add a new boolean Element property "canRequestFullScreen". This would map to Firefox's "Never" permission choice. >>> - Add the "fullscreendenied" event. This would map to Firefox's "Not now" permission choice. >> >> So if the user just dismisses the notification without picking any of the choices then "fullscreendenied" would fire in this proposal? > > I'm not trying to tell Firefox how to write their UI. And I would never suggest requiring this behavior in a spec. But, for the purposes of exploring this proposal, yes. Sure; the question was about how this proposal could work in existing permissions systems; not at all limited to Firefox. >> What happens if the user then reopens the notification and selects "Allow"? > > Assuming the targetted element still exists, and that the page hasn't issued a cancelFullScreen() request (or perhaps either of those conditions would cause the notification to disappear?) then the page enters full-screen mode and generates a "fullscreenchange" event. > > Yeah, it's somewhat weird to get a "fullscreenchange" event after a "fullscreendenial". But the spec already specifies that "The user agent may transition a Document into or out of the full-screen state at any time, whether or not script has requested it". So the devoloper must already expect un-requested "fullscreenchange" events. Ah, ok. I could probably live with this. It still leaves weirdness in Chrome, though, or other systems with a more persistent UI than Firefox's current notification popus, if the user doesn't dismiss the notification at all... -Boris
Received on Thursday, 12 May 2011 11:26:17 UTC