Re: [pointerlock] Various comments
While we're on the subject of pointer lock, I'm concerned about what happens when the pointer is removed while in pointer lock. New devices such as a Microsoft Surface have the pointing device as a trackpad embedded with a detachable keyboard. What happens when the user is pointer locked, they detach said keyboad and thus the pointer too? Now they only have touch input, no pointer, since the only pointer they had was the trackpack on the keyboard that they just detached. Traditional laptops and desktop PCs won't be detaching their pointers very frequently, but new form factor devices will do so more frequently and are more likely to hit this issue. Perhaps we should add text to the spec to say that pointer lock should be exited if all pointers are detached from the device? And should requests for pointer lock on devices without a pointer (like a touch-screen tablet for example) be specified to automatically fail? Regards, Chris Pearce. On 1/10/2014 4:08 AM, Ms2ger wrote: Hi Vincent, I have by no means reviewed the entire spec, but while reviewing the test cases, I noticed some room for improvement. Comments below. In the 4. pointerlockchange and pointerlockerror Events section [1]: … with its |bubble| attribute set … should be |bubbles|. Probably best to link to the definition in DOM, too. If you add attributes to MouseEvent, you should also add them to the MouseEventInit dictionary, so they can be initialized. Defaults should be defined for those attributes in prose too, for the createEvent case. Text could be: # When an event is created, the attribute must be initialized to […]. In the definition of requestPointerLock [2], a reference to DOM 3 Core is made; it looks like it should be to DOM 3 Events or UI Events instead. In section 6.1 Attributes, the writable attributes have two consecutive commas in their definition: onpointerlockchange of type EventHandler, , nullable Possibly a ReSpec bug; if so, please report to whereever such issues should be reported. In general, the prose could be made less ambiguous. For example, the definition of exitPointerLock: # Initiates an exit from pointer lock state if currently locked to a # target in this document, and sends a pointerlockchange event when the # lock state has been exited. # # The system mouse cursor must be displayed again and positioned at the # same location that it was when pointer lock was entered (the same # location that is reported in screenX/Y when the pointer is locked). could be rewritten as: | 1. If the pointer is not currently locked to a target in the | context object, terminate these steps. | 2. Exit the lock state. [Or should this be queued too? An | unambiguous specification would have answered this | question.] | 3. Display the system mouse cursor again, positioned at the | same location that it was when pointer lock was entered. | 4. Deliver [link to section 4. pointerlockchange and | pointerlockerror Events] a |pointerlockchange| event to the | context object. | Note: this is the same location that is reported in | screenX/Y when the pointer is locked. The dfn-exitpointerlock id is on an empty dfn element, which seems pretty silly. HTH Ms2ger [1] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#pointerlockchange-and-pointerlockerror-events [2] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#widl-Element-requestPointerLock-void
Re: pointerLock vendor prefixes, shims and usability
- Original Message - From: Florian Bösch pya...@gmail.com To: Webapps WG public-webapps@w3.org Sent: Tuesday, December 25, 2012 8:01:47 AM Subject: pointerLock vendor prefixes, shims and usability The pointerlock API is currently prefixed with vendor prefixes. This is fine in principle since it is an experimental API that lacks consistency and consensus and that's what vendor prefixes are for. A vendor prefix should serve to inform a developer that he's using non-standard functionality that may break or change, I get it, that's fine. It is however inconvenient to write out moz/o/msie/webkit/etc. everywhere in your code. Shims are one solution to this issue which enjoys some popularity (other people call it polyfill). You cannot write a shim/polyfill for pointerlock for the following reasons: - vendorRequestPointerLock is on the prototype to HTMLElement which you cannot modify in Firefox - vendorMovementX etc. are set by the event construction to mousemove, one cannot override and wrap the HTMLElement prototypes addEventListener. Even if one could, one would not want to allocate an object for every event in JS userspace (GCing being hurtful to realtime applications) - vendorpointerlockchange events can likewise only be abstracted by overriding HTMLElement's prototype which is a nogo. - document.mozPointerLockElement cannot be shimmed at all obviously (you cannot listen to document property changes) Toji Game Shim seems to shim pointer lock fine in Firefox and Chrome release builds. https://github.com/toji/game-shim Chris Pearce.
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
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
would really need alpha-numeric keyboard access are games, or 3D
modellers, like CAD software.
On 19/10/12 14:31, Feross Aboukhadijeh wrote:
I wrote the attack demo that prompted this discussion. Here are my
thoughts on how to improve the spec and/or the implementations in
browsers:
requestFullscreen() should trigger fullscreen mode with limited
keyboard input allowed (only space, arrow keys, and perhaps some
modifier keys like CTRL, ALT, etc.). The browser should display a
notification that the user is in fullscreen mode, although it can fade
away after some time since the risk of phishing is significantly
reduced when keyboard input is limited (note that Safari currently
sees fit to show NO notification at all about fullscreen mode because
keyboard is limited).
This level of functionality will support 90% of current fullscreen use
cases like video players, slideshow viewers, and games with simple
input requirements.
However, the spec should also support an optional ALLOW_KEYBOARD_INPUT
parameter to requestFullscreen() which, when passed, triggers
fullscreen mode with full keyboard support (except for ESC to exit
fullscreen). When this parameter is passed, the browser should show a
prominent modal dialog on top of the page content, requesting
permission to use fullscreen mode. No keyboard or mouse input should
be allowed until the user clicks Allow.
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 access. In
those cases making the user aware that they've entered fullscreen is
pretty much the best defence the user has. Other than not having a
fullscreen API at all.
Our fullscreen approval UI in Firefox is based around the assumption
that for most users the set of sites that use the fullscreen API that
the user encounters on a daily basis is small, and users would tend to
opt to remember the fullscreen approval for those domains. I'd imagine
the set would be YouTube, Facebook, and possibly ${FavouriteGame}.com
for most users. Thus users would see a notification and not an approval
prompt /most of the time/ when they entered fullscreen. But when some
other site goes fullscreen they do get a prompt, which is out of the
ordinary and more likely to be read.
Chris Pearce
Re: full screen api
On 13/10/12 07:20, Carr, Wayne wrote: There’s a recent post on a phishing attack using the full screen api [1][2}[3]. It's worth noting that this attack has been possible in Flash for years, and the sky hasn't fallen. Running the example attack, Firefox and Chrome both put up a popup at the top saying the site has gone full screen and asking to approve or deny. But for both of them the screen is already full screen and active (Firefox greys the content but doesn’t disable it). So if the user doesn’t see the popup or ignores it, they can think they’re interacting with another site. In the example, it is a bank. Why not require in the spec that it doesn’t go full screen until after the user approves? This is basically for scripts/authors' benefit. If permission must be requested before entering fullscreen there's no way for script to distinguish between the case of the user being about to approve/deny the permisison request, or the user having ignored the permission request. So it's harder for script to know whether/when it should take its fallback path. However I believe the current specification could be interpreted to allow a permission prompt before entering fullscreen; the specification for requestFullscreen() says it runs asynchronously, which gives scope for a permission request before or approval request after entering fullscreen. That would at least force the user to pay attention to the popup. If you're going to argue that people won't pay attention to an approval prompt shown after entering fullscreen, then the same argument also applies to showing the approval UI before entering fullscreen. Regards, Chris Pearce.
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
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. Regards, Chris Pearce.
Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 27/09/12 08:37, Vincent Scheib wrote: On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 9/26/12 11:46 AM, ext Vincent Scheib wrote: On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Pointer Lock - Vincent - what's the status of the spec and its implementation? Firefox 14 and Chrome 22 shipped Pointer Lock implementations to stable channel users recently. (Check out this Mozilla demo https://developer.mozilla.org/en-US/demos/detail/bananabread, using either.) Pointer Lock specification did have minor adjustments (inter-document and iframe sandbox security issues, pending state and mouse movement clarifications). diffs: http://dvcs.w3.org/hg/pointerlock/log/default/index.html So, I'm happy to prepare an updated working draft. Thanks for the update Vincent! Do you and/or the implementers consider the spec feature complete, which is a major factor to determine if the spec is Last Call ready (other considerations are documented at [1])? There are no known issues, and no known additional features. We haven't seen many applications developed yet, but there have been a few functionally complete demos. Reading over [1] I believe it is Last Call Ready. I agree. No one involved on our side of things is aware of any remaining issues with the pointer lock spec. Chris Pearce (Mozilla's pointer lock implementation maintainer)
Scrolling when document.documentElement requests fullscreen
We've had a couple of bugs filed against Gecko recently about scrolling
fullscreen content.
Currently behaviour differs between Chrome and Gecko when fullscreen is
requested on document.documentElement. When this happens Chrome still
shows the viewport/browser scrollbars, but Gecko does not show viewport
scrollbars.
For example, compare the behaviour of
http://robnyman.github.com/fullscreen/index-high-content.html in Chrome
and Firefox.
Our developer evangelists tells us that authors intuitively expect
scrollbars when requesting fullscreen on document.documentElement.
Authors expect that since the document is scrollable (via the viewport
scrollbars) before entering fullscreen it should remain scrollable after
entering fullscreen.
Gecko does not show viewport scrollbars when requesting fullscreen on
document.documentElement since the :fullscreen psuedoclass's
position:fixed positioning styles cause it to be unscrollable. I don't
know why Chrome shows scrollbars in this case.
We're proposing in the relevant Mozilla bug [1] to change our
implementation so that the :fullscreen pseudoclass rule is :not(:root).
This would mean that document.documentElement would still be scrollable
after entering fullscreen, which would then match authors' expectations.
i.e.:
*|*:not(:root):fullscreen {
position: fixed;
top:0; right:0; bottom:0; left:0;
/* etc... */
}
Before I make this change in Gecko I'd like to get consensus from other
implementers that we want this behaviour, and get the spec changed to
reflect that.
Regards,
Chris Pearce.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=779286#c18
Re: Fullscreen events dispatched to elements
On 2/06/2012 11:19 a.m., Vincent Scheib wrote: IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Because of this, the spec was then changed to dispatch fullscreenchange to the context element on entering fullscreen, and to the document on exit, but we found this inconsistent, since a listener has to listen to multiple nodes to receive both exit and enter events, so the spec was changed again to always dispatch fullscreenchange to the document. Regards, Chris P.
Re: [fullscreen] fullscreenEnabled and the fullscreen enabled flag
On 19/05/2012 4:25 a.m., Anne van Kesteren wrote: Chris Pearce is not on this mailing list. Chris are you okay with moving discussion to here? Anyone else who should be kept in the loop? I'm happy to move the discussion to public-webapps, thanks for the heads up. Cheers, Chris P.
