On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak wrote:
> On Dec 18, 2012, at 6:44 AM, Anne van Kesteren wrote:
>> The specification is modeled after Gecko and Chrome and very much
>> intents to have keyboard access working. As per usual, everything that
>> is not restricted is expected to work
On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak wrote:
> And given this difference in UA behavior, it seems useful to let web
> developers feature-detect the difference in behavior somehow.
>
It would be useful to be able to detect it. But it's in no way cruical, we
can just do if($.browser.sa
On Dec 18, 2012, at 6:44 AM, Anne van Kesteren wrote:
> On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak wrote:
>> Based on all this, I continue to think that requesting keyboard access
>> should involve separate API, so that it can be feature-detected and given
>> different security treatme
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak wrote:
> Based on all this, I continue to think that requesting keyboard access
> should involve separate API, so that it can be feature-detected and given
> different security treatment by vendors as desired. This is what Flash does,
> and they
On Monday, October 22, 2012 at 6:04 PM, Chris Pearce wrote:
> On 16/10/12 18:48, Maciej Stachowiak wrote:
> > Many games could work with only non-alphanumeric keys or in some cases only
> > the mouse. As could slideshows. You only need space/enter/arrows for a full
> > screen slide presentatio
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak wrote:
> Based on all this, I continue to think that requesting keyboard access
> should involve separate API, so that it can be feature-detected and given
> different security treatment by vendors as desired. This is what Flash
> does, and they
On Oct 22, 2012, at 3:04 PM, Chris Pearce wrote:
>
> This looks remarkably like Mozilla's original proposal:
> https://wiki.mozilla.org/Gecko:FullScreenAPI
>
> We chose not to implement this as it offers little protection against
> phishing or spoofing attacks that don't rely on keyboard acce
FYI Flickr slideshows and Google street view are now fullscreen users.
On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce wrote:
> On 16/10/12 18:48, Maciej Stachowiak wrote:
>
> Many games could work with only non-alphanumeric keys or in some cases
> only the mouse. As could slideshows. You only n
On 16/10/12 18:48, Maciej Stachowiak wrote:
Many games could work with only non-alphanumeric keys or in some cases
only the mouse. As could slideshows. You only need space/enter/arrows
for a full screen slide presentation.
FWIW I agree. Pretty much the only uses cases that I can envisage that
going
> full screen.
>
> >-Original Message-
> >From: Jonas Sicking [mailto:jo...@sicking.cc]
> >Sent: Wednesday, October 17, 2012 1:44 AM
> >To: Carr, Wayne
> >Cc: Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org; Chris
> Pearce;
> >Floria
From:* Florian Bösch [mailto:pya...@gmail.com]
> *Sent:* Thursday, October 18, 2012 7:08 PM
> *To:* Feross Aboukhadijeh
> *Cc:* Carr, Wayne; Jonas Sicking; Vincent Scheib; Maciej Stachowiak;
> public-webapps@w3.org; Chris Pearce; Anne van Kesteren
>
> *Subject:* Re: Defenses aga
On Fri, Oct 19, 2012 at 9:08 AM, Feross Aboukhadijeh wrote:
> "Apple has also indicated of not liking confirm prompts of any kind
> whatsoever"
>
> To reiterate: for 90% (probably more) of fullscreen use cases, there would
> be no confirmation prompt at all. Only when the developer specifically
>
On Fri, Oct 19, 2012 at 4:50 AM, Carr, Wayne wrote:
> If touch events are restricted, how does the user pause the video?
>
If you do not disable click/touch on devices with an onscreen keyboard, how
do you defend against phishing?
Kesteren
Subject: Re: Defenses against phishing via the fullscreen api (was Re: full
screen api)
Note that that's a related but not identical stage of the process. There will
still have to be a way to differentiate how to request fullscreen with those
capabilities that you queried as being
>
>>> And it can be detectable to the web page - it can be the full screen
>>> notification doesn't happen until after the user has approved it.
>>>
>>> There are different approaches today, but none of them prevent the user
>>> from interacting
t.
>>
>> There are different approaches today, but none of them prevent the user
>> from interacting with the full screen app before they've approved it going
>> full screen.
>>
>> >-Original Message-
>> >From: Jonas Sicking [mailto:jo...@
AM
>To: Carr, Wayne
>Cc: Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org; Chris Pearce;
>Florian Bösch; Anne van Kesteren
>Subject: Re: Defenses against phishing via the fullscreen api (was Re: full
>screen
>api)
>
>On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne wro
On Wed, Oct 17, 2012 at 12:06 PM, Florian Bösch wrote:
> On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron wrote:
>
>> I'm not sure where this falls, but how would things like control-w or
>> cmd-w work? If the non-alphanumerics work, but the alphanumerics do not...
>> will that close the window?
>>
On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron wrote:
> I'm not sure where this falls, but how would things like control-w or
> cmd-w work? If the non-alphanumerics work, but the alphanumerics do not...
> will that close the window?
>
Far as I understood it the "keyboard disabled" refers to keyboar
On Tue, Oct 16, 2012 at 5:42 AM, Florian Bösch wrote:
> On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak wrote:
>
>> What are the cases where webpage-driven (as opposed to
>> browser-chrome-driven) fullscreen is really compelling, but they need full
>> keyboard access including alphanumeric ke
On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne wrote:
>> Chrome supports Fullscreen with keyboard enabled. We use a notification
>> that persists until a user notices and
>> dismisses it. We may modify it in the future to make this more noticeable,
>> e.g. dimming page contents similar to FireFox.
>
onded to the
notification.)
From: Vincent Scheib [mailto:sch...@google.com]
Sent: Tuesday, October 16, 2012 1:57 PM
To: Maciej Stachowiak
Cc: Chris Pearce; Florian Bösch; Anne van Kesteren; Carr, Wayne;
public-webapps@w3.org
Subject: Re: Defenses against phishing via the fullscreen api (was Re:
On Tue, Oct 16, 2012 at 10:56 PM, Vincent Scheib wrote:
> However, if other browsers only implement fullscreen without keyboard
> support then clearly it would be best if developers could detect this when
> composing their application interface, avoiding prompting users to enter
> fullscreen if i
Chrome supports Fullscreen with keyboard enabled. We use a notification
that persists until a user notices and dismisses it. We may modify it in
the future to make this more noticeable, e.g. dimming page contents similar
to FireFox.
I personally think it would be unfortunate to support multiple mo
On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak wrote:
> What are the cases where webpage-driven (as opposed to
> browser-chrome-driven) fullscreen is really compelling, but they need full
> keyboard access including alphanumeric keys? (Not saying there aren't any,
> I am just not sure what th
On Oct 15, 2012, at 5:01 PM, Chris Pearce wrote:
> 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 b
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 f
A function to query the capabilities obtainable after entering fullscreen
would also work from an application developers point of view:
navigator.fullscreenCapability.keyboard -> true/false
navigator.fullscreenCapability.mouse -> true/false
navigator.fullscreenCapability.ui -> true/false
navigator
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. I think the spec should change b
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?
On Oct 14, 2012, at 3:54 PM, Chris Pearce 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 ap
On Mon, Oct 15, 2012 at 12:54 AM, Chris Pearce wrote:
> 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.
>
An implementation, all
On 14/10/12 00:49, Maciej Stachowiak wrote:
On Oct 13, 2012, at 1:49 AM, Anne van Kesteren wrote:
On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch wrote:
There was a limited discussion on that a few days ago with the limited
consensus (?) being that requiring user-consent up front before switc
WebGL FPSes with fullscreen support
- http://media.tojicode.com/q3bsp/
- https://developer.mozilla.org/en-US/demos/detail/bananabread
- http://dl.dropbox.com/u/6873971/data/cube2/index.html
On Sat, Oct 13, 2012 at 9:58 PM, Florian Bösch wrote:
> You're making fullscreen useless for games.
>
>
>
You're making fullscreen useless for games.
On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak wrote:
>
> On Oct 13, 2012, at 4:58 AM, Florian Bösch wrote:
>
> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote:
>
>> I think the most effective defense against phishing via fullscreen is t
On Oct 13, 2012, at 4:58 AM, Florian Bösch wrote:
> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote:
> I think the most effective defense against phishing via fullscreen is to
> prevent keyboard access. The original design for requestFullscreen had an
> optional argument for requesti
On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote:
> I think the most effective defense against phishing via fullscreen is to
> prevent keyboard access. The original design for requestFullscreen had an
> optional argument for requesting keyboard access, which led to a warning in
> some bro
37 matches
Mail list logo
