On 16/10/12 11:39, Maciej Stachowiak wrote:
That's why I liked having a separate API to request fullscreen with
full alphanumeric keyboard access. This allows apps to determine if
fullscreen with keyboard is available on a given browser, and allows
browsers to set separate security policies for that case.
Would you implement keyboard access in fullscreen via this API if we
spec'd it? Or are you looking for a way to for authors to determine if
key input isn't supported in fullscreen mode?
I think the spec should change back to having two distinct APIs, even
though Mozilla is not interested in making a distinction between the
two cases.
I'd say fullscreen video is the only fullscreen use case where page
script shouldn't need key events dispatched to it. I'm sure some other
fullscreen uses wouldn't want key events, but most non-trivial users of
fullscreen would want keyboard shortcuts or input.
Anyway, I'm curious what the Chrome guys think.
Chrome's requestFullscreen implementation takes a parameter/flag
Element.ALLOW_KEYBOARD_INPUT to denote whether key input should be
allowed. I thought they ignored that and just always allowed key input
fullscreen, but I see now that they do honour it.
Regards,
Chris P.
Regards,
Maciej
On Oct 15, 2012, at 3:45 AM, Florian Bösch <pya...@gmail.com
<mailto:pya...@gmail.com>> wrote:
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 <m...@apple.com
<mailto:m...@apple.com>> wrote:
On Oct 14, 2012, at 3:54 PM, Chris Pearce <cpea...@mozilla.com
<mailto:cpea...@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
