Ok, so here's my question. You have a webapp (that oh, happens to be a game, or a slideshow app, or a video player with controls, etc.) which needs keyboard/UI events access to work (come to think of it, can you honestly think of any sort of usecase that does work entirely without user intercation?). Anyways, so now this app needs to figure out if it's worth the bother to even display a fullscreen icon/request fullscren (see, after all, there woulnd't be a point if there's no keyboard/UI access). So how does an app do that? How do we figure out what the random behavior changes are that vendors add, that would break our app, that make it pointless to try to use the API on that vendors browser? Anyone? On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > On Oct 14, 2012, at 3:54 PM, Chris Pearce <cpearce@mozilla.com> wrote: > > > On 14/10/12 00:49, Maciej Stachowiak wrote: > >> > >> Despite both of these defenses having drawbacks, I think it is wise for > implementations to implement at least one of them. I think the spec should > explicitly permit implementations to apply either or both of these > limitations, and should discuss their pros and cons in the Security > Considerations section. > > > > > > I don't support making these mandatory, but they should certainly be > added to the Security Considerations section; we considered them, and we > may indeed re-consider them in future if it proves necessary. > > > > I support making the spec general enough that implementors can chose > their security features based on their requirements; what's appropriate for > a desktop browser may not be appropriate for a tablet, for example. > > I agree with both of these comments (in case it wasn't clear). I suggest > that these mechanisms should be permitted, not mandatory. Right now it is > not entirely clear if either is permitted per spec. > > Regards, > Maciej > >
Received on Monday, 15 October 2012 10:45:43 UTC