Re: CFC: Republish Pointer Lock as CR
I've discussed more with Xiaoqian and Léonie and support a CR now with this proposal: Move to a CR for the v1 Pointer Lock specification without Shadow DOM changes, and a note on accessibility. Implementations are nearly consistent for v1 and it can move to a published status sooner. We can follow up with a v2 requiring more implementation work afterwards.
Re: CFC: Republish Pointer Lock as CR
Shadow dom concepts will also be incorporated. On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com> > wrote: > > An accessibility review and handling of this [accessibility issue #1] are >> still needed and will likely cause a CR cycle. To avoid unnecessary work >> I propose CR to be deferred until that work is complete. >> >> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1 >> > > Agreed, that makes good sense. I'll try to help that get done as fast as > we can. > > cheers > > > On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell <dylan.barr...@deque.com> >> wrote: >> >> abstain >>> >>> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl> wrote: >>> >>> Looks good, +1 >>>> >>>> —Michiel >>>> >>>> On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk> wrote: >>>> >>>> Hello WP, >>>> >>>> This is a Call For Consensus (CFC) to request that W3C republish Pointer >>>> Lock as a Candidate Recommendation (CR). Extensions to the >>>> MouseEventInit >>>> Dictionary [1] constitute substantive changes to the specification that >>>> were >>>> made after the current CR was published in 2013 [2]. >>>> >>>> Please reply to this CFC no later than 21st June 2016. Positive >>>> responses >>>> are preferred and supporting comments (beyond just +1) are encouraged, >>>> but >>>> silence will be considered as consent. >>>> >>>> Thank you. >>>> >>>> Léonie on behalf of the WP chairs and team, and Pointer Lock editor. >>>> [1] >>>> >>>> >>>> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona >>>> ry >>>> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ >>>> -- >>>> @LeonieWatson tink.uk Carpe diem >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Download the aXe browser extension for free: >>> >>> Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools >>> Chrome: >>> >>> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US >>> >>> Life is ten percent what happens to you and ninety percent how you >>> respond >>> to it. - Lou Holtz >>> >>> >>> > > -- > Charles McCathie Nevile - web standards - CTO Office, Yandex > cha...@yandex-team.ru - - - Find more at http://yandex.com > >
Re: CFC: Republish Pointer Lock as CR
An accessibility review and handling of this [accessibility issue #1] are still needed and will likely cause a CR cycle. To avoid unnecessary work I propose CR to be deferred until that work is complete. [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1 On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrellwrote: > abstain > > On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl wrote: > >> Looks good, +1 >> >> —Michiel >> >> On 13 Jun 2016, at 18:12, Léonie Watson wrote: >> >> Hello WP, >> >> This is a Call For Consensus (CFC) to request that W3C republish Pointer >> Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit >> Dictionary [1] constitute substantive changes to the specification that >> were >> made after the current CR was published in 2013 [2]. >> >> Please reply to this CFC no later than 21st June 2016. Positive responses >> are preferred and supporting comments (beyond just +1) are encouraged, but >> silence will be considered as consent. >> >> Thank you. >> >> Léonie on behalf of the WP chairs and team, and Pointer Lock editor. >> [1] >> >> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona >> ry >> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ >> -- >> @LeonieWatson tink.uk Carpe diem >> >> >> >> >> > > > -- > Download the aXe browser extension for free: > > Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools > Chrome: > https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US > > Life is ten percent what happens to you and ninety percent how you respond > to it. - Lou Holtz > >
Re: [pointerlock] Oct 2015 Pointer Lock Status
On Sun, Nov 1, 2015 at 3:42 AM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Yes. You are *not* required to use testharness tests. While it would be > good to get the automation of stuff like this landed, it is perfectly > reaonable to write some interop tests in the form "load this page and do > this and then this and then this, and determine whether you see this or > that". A set of tests of this nature that collectively cover the spec's > features should be enough. And it is a Good Thing™ to use content found in > the wild as the basis for this. > Thanks for clarifying. Basic usage is demonstrated in the wild but some edge cases should have clear demonstration in the test suite. I will generate those as other project priorities allow (and would of course review any from others). If it is implemented in multiple browsers, is used by websites "in the > wild", and you can show that it has been looked over to see if concerns > were indentified relating to accessibility, API design, > internationalisation, privacy, and security, we probably have sufficiently > wide review to request Proposed Rec. > > A lot of that is already reflected in the spec. The cases of accessibility > that strike me as relevant are being able to generate synthetic mouse > events, e.g. with keyboard, escape pointer lock, and making sure that users > understand when they have been put into it - especially for users with > cognitive disabilities. > Thanks. Accessibility should be addressed more explicitly in the specification. I will reach out to the APA and solicit suggestions.
Re: [pointerlock] Oct 2015 Pointer Lock Status
On Thu, Oct 29, 2015 at 12:18 AM, Michael[tm] Smith <m...@w3.org> wrote: > Hi Vincent, > > Vincent Scheib <sch...@google.com>, 2015-10-23 13:57 -0700: > > Testharness tests are not currently able to test the core Pointer Lock > > features, which would require user gesures (mouse clicks) and > synthesizing > > mouse movement. No progress is seen here for this specification, but the > > challenge is present for several. E.g. Web Bluetooth brought up this > > concern recently [Platform Testing] on public-test-infra, but with no > > response. I have requested Jeffrey Yasskin and Sam Uong from Chrome to > > discuss this topic at TPAC. > > To make the needed WebDriver integration into testharness.js happen, the > main thing we have been lacking for more than year or so now is an engineer > committed to spending the weeks of time (say, three months) needed to do > the actual hands-on work of designing it and implementing it and landing > it. > > Hopefully we may finally now be reaching the point where we have critical > mass of people who need to see it happen sooner rather than later. > Good to hear. I should note that for Pointer Lock we would need to carefully spec mouse input at quite a low level, and in a way that will work to fake different OS APIs of mouse change notifications.
[pointerlock] Oct 2015 Pointer Lock Status
Pointer lock reached Candidate Recommendation in Dec 2013. [CR] Implementation status: (Edge and Opera have changed status since October 2014) Chrome: Implemented. Firefox: Implemented with prefix. Edge: Implemented in Preview Build 10532+ (Edge 13) [Edge] Opera: Implemented. Safari: No implementation progress known. http://caniuse.com/#search=pointer summarizes this well. Test suite (has not changed since Jan 2014): Two basic tests exist: http://w3c-test.org/pointerlock/constructor.html http://w3c-test.org/pointerlock/idlharness.html * Firefox fails due to prefixing. * Chrome & Opera fail IDL tests due to seemingly unrelated issues. Testharness tests are not currently able to test the core Pointer Lock features, which would require user gesures (mouse clicks) and synthesizing mouse movement. No progress is seen here for this specification, but the challenge is present for several. E.g. Web Bluetooth brought up this concern recently [Platform Testing] on public-test-infra, but with no response. I have requested Jeffrey Yasskin and Sam Uong from Chrome to discuss this topic at TPAC. Specification: https://w3c.github.io/pointerlock/ Minor changes in last year (small IDL fixes, typos/grammar): https://github.com/w3c/pointerlock/commits/gh-pages Feature Requests page moved to github: https://github.com/w3c/pointerlock/blob/gh-pages/FeatureRequests.md Next Steps: In the Candidate Recommendation Call for Comments [CR-CfC] Arthur Barstow proposed exit criteria: """ During the Candidate Recommendation period, which ends @T+3months, the WG will complete its test suite. Before this specification exits Candidate Recommendation, two or more independent implementations must pass each test, although no single implementation must pass each test. The group will also create an Implementation Report. """ Robust cross browser testing, as mentioned above, is challenging and I question if browser vendors will implement sufficient support, e.g. via Web Driver or other means. This leaves a discussion of how much testing is practical vs implicit demonstration of implementation consistency via application use. Feature use exists in typically smaller projects. For example http://a-way-to-go.com/. Potential for higher use remains. 3D game engines exist, and a significant industry tool Unity 3D continues to improve their HTML export. [Unity3D HTML5] Working group questions: * How much testing is practically required to move to Proposed? * Ready for 'wider' review? [CR] https://www.w3.org/blog/news/archives/3529 [CR-CfC] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0648.html [Edge] https://dev.modern.ie/platform/status/pointerlockmouselock/?filter=f3fbf=pointer%20lock [Platform Testing] https://lists.w3.org/Archives/Public/public-test-infra/2015JulSep/0017.html [Unity3D HTML5] http://docs.unity3d.com/Manual/webgl-building.html
Re: Pointer lock spec
can be established ahead of time. e.g. - User visits site, and enters application. - Anticipating need for pointer lock, the application displays explanatory text and invites user to click a button for the initial prompt. requestPointerLock is called. - User accepts the pointer lock permission. - Application immediately releases lock, as it won't be needed until later. Alternatively: - User visits site, and enters application. - User attempts a drag operation - Application attempts to lock pointer, but lock is not entered. - Application handles mouse move events until mouseup. Doing a best effort action that the drag was used for (e.g. panning viewport). - Application shows a message, Hey, when you drag we'd like to make the experience better, but you'll need to accept the permission prompt. 1. When he clicks allow, the mouse will be captured, but the release event might not have been dispatched, so that the event order suggests the pointer is captured, though that would run counter the semantic (I'm not sure what the current UA behavior there is, but this was the case in some UAs as of a year ago) That would be an implementation bug, the specification doesn't alter the dispatching of mouseup. Chrome doesn't seem to have this bug now. html body onload= document.body.onclick = function () { output.innerHTML += 'click\n'; } document.body.onmousedown = function () { output.innerHTML += 'down\n'; document.body.requestPointerLock(); } document.body.onmouseup = function () { output.innerHTML += 'up\n'; } pre id=output outputs down up click and the permission bubble is shown. 1. Regardless of previous pointer capture confirmation, some UAs choose to display a popup with information everytime somebody enters pointerlock, which makes frequenty entry/exit fr This is a UA implementation decision, and it may change over time. E.g. Chrome may decide that pointer lock while in fullscreen and with keyboard lock is too risky to not show some reminder that pointer lock has been re-entered. Today, Chrome does not show a reminder UI when pointer lock is entered it if was previously exited by exitPointerLock. This was used by cloudparty.com (now defunct) as they entered pointer lock only during a drag, and did so without annoying UI. You can test this today on http://scheib.github.io/HTMLMisc/PointerLockAndFullscreen.html by entering a lock, using Unlock Pointer button at top to leave, and then re-entering. I'd also like to expand a bit on the topic of high resolution pointer information, which means both high temporal and high spatial resolution. For example The Razer Ouroboros mouse ( http://www.razerzone.com/gaming-mice/razer-ouroboros). It supports a polling frequency of 1000hz and has a resolution of 8200dpi. OSes (after they're done mangling pointers trough their machinery) clamp pointer positions to pixels, and they clamp frequency of events at least to pixel crossover of the pointer and to no more than 60hz or so. It would be highly desirable to get sub-pixel accuracy of a pointing device (as is supported by nearly all mice produced in the last 10 years) as well as higher spatial frequency than the one imposed by the OSes pointer machinations. These things are desirable because they allow an application that runs say a 60hz display frequency, to temporally sub-sample a pointer location from say 16 different events. So even though at the start and end of a frame, the pointer might be in the same position again, a movement intra-frame could still be registered, smoothed and used. More generally this is useful to provide a smooth feel and rapid response to applications that deal with a need to use pointers for fast and/or accurate pointing (such as for instance FPS shooters). I agree this would be great, we discussed this in 2011 as well. It is included in https://www.w3.org/wiki/Webapps/PointerLockFeatures for consideration in a future iteration of the spec. It would be good to note any other developers who would find that useful, especially if they have a deployed product. On Thu, Feb 26, 2015 at 8:21 PM, Vincent Scheib sch...@google.com wrote: Thanks, Philip, changes made. On Thu, Feb 26, 2015 at 10:58 AM, Philip Jägenstedt phil...@opera.com wrote: Also, the EventHandler type should not be nullable, it's already typedef'd to be nullable in https://html.spec.whatwg.org/#eventhandler On Fri, Feb 27, 2015 at 1:56 AM, Philip Jägenstedt phil...@opera.com wrote: https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html The section Element Interface should be Extensions to the Element Interface to match the other sections, and because it's true :) Philip
Re: Pointer lock spec
Thanks, Philip, changes made. On Thu, Feb 26, 2015 at 10:58 AM, Philip Jägenstedt phil...@opera.com wrote: Also, the EventHandler type should not be nullable, it's already typedef'd to be nullable in https://html.spec.whatwg.org/#eventhandler On Fri, Feb 27, 2015 at 1:56 AM, Philip Jägenstedt phil...@opera.com wrote: https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html The section Element Interface should be Extensions to the Element Interface to match the other sections, and because it's true :) Philip
Re: [Bug 27709] New: Dictionary MouseEventInit uses keyword attribute for its members
I could use more information here. http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent specifies MouseEvent attributes with the attribute keyword. WebIDL description of attribute seems to apply here http://www.w3.org/TR/WebIDL/#idl-attributes. Why shouldn't the attribute keyword be used?
Re: [Pointer Lock] Comments
Thank you again: https://dvcs.w3.org/hg/pointerlock/rev/25ad122a8000 On Tue, Dec 2, 2014 at 6:43 PM, timeless timel...@gmail.com wrote: 1. w3c is en-us https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract modelling - modeling Done. 2. Xlib https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the cursor to a specific rectangle, and prototypes have not yet been developed to demonstrate building that behavior by e.g. invisible windows with xlib or manual cursor movement on Mac. Xlib - Wikipedia, the free encyclopedia -- http://en.wikipedia.org/wiki/Xlib Done. Linked to definition. Also note that Mac is not a proper term, it could be Mac OS (X), Macintosh ... or macs. Done. Expanded to more formal names. 3. Mouse capture https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE]. should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted? Done. MS should probably be referenced: http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx since it's their fault... Done. 4. a11y/i18n https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture An event generated by the user agent as a result of user interaction intended to interact with the page. e.g. click, but not mousemove. Engagement gestures are any events included in the definition of being allowed to show a popup with the addition of keypress and keyup. shift, or control+shift and similar things are often used to trigger an assistive technology, or an IME / language switch. https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true turn StickyKeys on or off by by pressing the SHIFT key five times http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT http://support.microsoft.com/kb/97738 When you press the APOSTROPHE (') key, QUOTATION MARK () key, ACCENT GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key, nothing appears on the screen until you press the a second key. If you press one of the letters designated as eligible to receive an accent mark, the accented version of the letter appears. If you press an ineligible key, two separate characters appear. In other words, the US-International keyboard layout dynamic-link library (DLL) automatically accents letters that customarily receive an accent but does not automatically accent letters that do not customarily receive an accent. While it's nice to allow for keys to trigger a lock, keys that may eventually be handled by something outside the UA should probably not be eligible for this. Done. user interaction intended to interact - user interaction processed by the user agent Added: Note that operating system level accessibility and internationalization features may intercept gestures before the user agent processes them for interaction with a page. E.g. multiple key press codes used to enter an extended international character. 5. must https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events Two events are used to communicate pointer lock state change or an error in changing state. They are named pointerlockchange and pointerlockerror. If pointer lock is entered or exited for any reason a pointerlockchange event must be sent. If I press ctrl-w/cmd-w (close window/tab), is the UA required to send these events? If an iframe has pointerlock, and its parent removes the iframe from the dom, is the UA required to send these events? If an iframe has pointerlock, and its parent changes the iframe's document url to another page, is the UA required to send these events? Help me pin down language. For each case above: Yes, If the document exists the events should be dispatched. Is more language needed to avoid the alternative implied assumption that a document must live until the events are dispatched? 6. and https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void (for example: mousemove, mousedown, mouseup, click, wheel) (for example: mouseover, mouseout, drag, drop). Done. Please use and -- you do elsewhere: clientX, clientY, screenX, and screenY 7. movement/focus https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void Movement and button presses of
Re: [Pointer Lock] Comments
Thank you for the detailed comments, I will incorporate and reply back. On Tue, Dec 2, 2014 at 6:43 PM, timeless timel...@gmail.com wrote: 1. w3c is en-us https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract modelling - modeling 2. Xlib https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the cursor to a specific rectangle, and prototypes have not yet been developed to demonstrate building that behavior by e.g. invisible windows with xlib or manual cursor movement on Mac. Xlib - Wikipedia, the free encyclopedia -- http://en.wikipedia.org/wiki/Xlib Also note that Mac is not a proper term, it could be Mac OS (X), Macintosh ... or macs. 3. Mouse capture https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE]. should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted? MS should probably be referenced: http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx since it's their fault... 4. a11y/i18n https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture An event generated by the user agent as a result of user interaction intended to interact with the page. e.g. click, but not mousemove. Engagement gestures are any events included in the definition of being allowed to show a popup with the addition of keypress and keyup. shift, or control+shift and similar things are often used to trigger an assistive technology, or an IME / language switch. https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true turn StickyKeys on or off by by pressing the SHIFT key five times http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT http://support.microsoft.com/kb/97738 When you press the APOSTROPHE (') key, QUOTATION MARK () key, ACCENT GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key, nothing appears on the screen until you press the a second key. If you press one of the letters designated as eligible to receive an accent mark, the accented version of the letter appears. If you press an ineligible key, two separate characters appear. In other words, the US-International keyboard layout dynamic-link library (DLL) automatically accents letters that customarily receive an accent but does not automatically accent letters that do not customarily receive an accent. While it's nice to allow for keys to trigger a lock, keys that may eventually be handled by something outside the UA should probably not be eligible for this. 5. must https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events Two events are used to communicate pointer lock state change or an error in changing state. They are named pointerlockchange and pointerlockerror. If pointer lock is entered or exited for any reason a pointerlockchange event must be sent. If I press ctrl-w/cmd-w (close window/tab), is the UA required to send these events? If an iframe has pointerlock, and its parent removes the iframe from the dom, is the UA required to send these events? If an iframe has pointerlock, and its parent changes the iframe's document url to another page, is the UA required to send these events? 6. and https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void (for example: mousemove, mousedown, mouseup, click, wheel) (for example: mouseover, mouseout, drag, drop). Please use and -- you do elsewhere: clientX, clientY, screenX, and screenY 7. movement/focus https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void Movement and button presses of the mouse must not cause the window to lose focus. Suppose I'm using Windows w/ a standard 104 key keyboard: http://en.wikipedia.org/wiki/Computer_keyboard#mediaviewer/File:Qwerty.svg If I press a system key (the Windows key), or a system key equivalent stroke (ctrl+esc), I expect the application to lose focus. http://developer.android.com/design/media/whats_new_nav_bar.png If I press the home key on an Android device, I expect the window to lose focus. If a user is on a system where there is no hardware home button, but there is a gesture which enables interacting with the system, the UA shouldn't be out of compliance. see Fast Quick Settings Access --
[pointerlock] Oct 2014 Pointer Lock Status
Implementation status: (Chrome and IE have changed status since April) Chrome: Implemented without prefix, in stable version. Firefox: Implemented with prefix, in stable version. IE: Implementation active. Issue: http://connect.microsoft.com/IE/feedback/details/793718/ie11-feature-request-support-for-pointer-lock-api Safari: No implementation progress known. Opera: No implementation progress known. Test suite (has not changed since April): Two basic tests exist: http://w3c-test.org/pointerlock/constructor.html http://w3c-test.org/pointerlock/idlharness.html After unprefixing, tests fail partially in Chrome. Firefox fails due to prefixing. Plan to complete test suite: - Implementations need to start using W3C tests that exist - More implementations need to support unprefixed pointer lock. - Chromium issue: https://code.google.com/p/chromium/issues/detail?id=359740 - More tests are needed. - I sense little prioritization from Chrome or Mozilla organizations to do this soon. IE with a new implementation may use the opportunity to create more testharness.js tests. Specification discussion: Previous extension discussion has been given a term Pointer Clip and notes added to https://www.w3.org/wiki/Webapps/PointerLockFeatures
Re: Proposal for a Permissions API
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch pya...@gmail.com wrote: Well, the motivation to ask for permission up front is so that you later don't have to pester the user. Everytime you poll a user, there's a possibility he'll not see the prompt (happens to me pretty frequently in chrome and firefox) and stuff won't work and the site makes a sad face. Putting it up front is one way to avoid a bad user experience. It's likely APIs that require permissions will proliferate, which makes it more likely to run into the bad cases. There are other motivations to put permissions up-front though. For instance if you enter pointerlock, then in order to click on the permissions, the browser needs to throw the user out of pointerlock, but you're not getting back into pointerlock by itself, so you need to reaquire it, which necessitates a user interaction. Sometimes a set of functionality (like say geolocation and user media) is often requested together, so it makes it again more likely to run into the bad cases. Pointerlock fullscreen solved this issue by coalescing the permission for both into a single dialog if both are requested. Merging pointer lock and fullscreen requests has worked well in Chrome, particularly allowing that merging to happen independently of request order or timing allowing for them to be joined after a delay. Additional UI presentations of this merging have been considered over time and the browser has great flexibility in how to guide the user through an informed choice. Continuing to support the browser merging requests is valuable. Merging doesn't require an API specifically built to bundle, also as demonstrated by pointer lock and fullscreen which Chrome merges without a unified or explicit API. However, code legibility, maintainability, and developer intent would all benefit. Ability to merge also doesn't imply that a webpage can not offer interstitial explanation of requests to increase user engagement. I'd also argue that users who click through unwarranted large permissions groups in order to access simple apps such as flashlights are just as likely to click multiple times to sequential requests.
Bluetooth API Community Group, call for support
Chrome is renewing work toward a Bluetooth API for websites to communicate with devices. We have started work reviewing existing APIs, use cases, and security concerns. [1] has a start of that work focusing on minimizing the device attack surface exposed to malicious websites, possibly by removing access to some existing Bluetooth features that are hard to implement securely. We'd also like the API to support a user interface to select and approve access to devices as opposed to using certification and installation. We have proposed a Community Group [2] to incubate this specification, and are soliciting supporters! [1] https://github.com/jyasskin/web-bluetooth [2] http://www.w3.org/community/blog/2014/07/30/proposed-group-web-bluetooth-community-group/
Pointer Lock Status
Implementation status: Chrome: Implemented with prefix, in stable version. Firefox: Implemented with prefix, in stable version. IE: No implementation progress known. Issue: http://connect.microsoft.com/IE/feedback/details/793718/ie11-feature-request-support-for-pointer-lock-api Safari: No implementation progress known. Opera: No implementation progress known. Test suite status: Two basic tests exist: http://w3c-test.org/pointerlock/constructor.html http://w3c-test.org/pointerlock/idlharness.html which fail in Chrome and Firefox due to prefixing, and likely correctness issues are masked by this. Plan to complete test suite: - Implementations need to start using W3C tests that exist - Thus implementations need to support unprefixed pointer lock. - Chromium issue: https://code.google.com/p/chromium/issues/detail?id=359740 - More tests are needed. - Chromium and Mozilla have possible candidates for upstreaming. - I sense little prioritization from either organization to do this soon. (Correct me if Mozilla has anyone available to do this) Additional specification discussion: Artillery started a discussion Problems with mouse-edge scrolling and games in public-webapps Feb 21 2014 raising the topic of limiting pointer movement to a rectangular area. This is addressed in the spec FAQ for why it is postponed from the initial version, and in the recent thread the result was a call for prototype. I don't have resources to build it out, though would accept others doing so. If this was done rapidly and Mozilla was interested in incorporating changes as well there's the possibility that Pointer Lock spec should be updated to include clipping. Otherwise, I believe a follow up specification at a later time is more appropriate, keeping Pointer Lock narrow and moving to complete the specification.
Re: [gamepad] preventing default/capturing controller
Perhaps I'm missing some context. What issue are you raising that isn't handled by the gamepad API [1]? [1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke re...@splintered.co.ukwrote: No takers on the idea of having some form of control - like a gamepad capture lock, or some way of preventDefault-ing gamepad controls before they're turned into mouse/cursor controls by the UA? On 26/02/2014 10:16, Patrick H. Lauke wrote: Currently, the only way for a gamepad to be used as input would be to emulate mouse or keyboard events I'm wondering if it's in scope for this spec to also address the situation where a UA *does* already do this natively (for instance, IE on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad firing cursor event. A few precedents that may be worth looking at: - Pointer Lock API http://www.w3.org/TR/pointerlock/ - Opera's spatial navigation on TV browsers, which can be preventDefault-ed if the website/app wants to handle d-pad input (mapped to cursor keys already, mind) on a remote control http://dev.opera.com/articles/view/functional-key-handling- in-opera-device-sdk-based-tv-browsers/#prevent-default - Boxee's (discontinued) API to explicitly switch browser into different modes (cursor, keyboard, player) http://developer.boxee.tv/JavaScript_API#Browser_Modes There's an argument that this should be left completely up to the UA, and that users should switch the UA into different modes. However, at the very least it would be nice then to have a way for a site/app to *signal* that it can handle direct gamepad input. Thoughts? P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Re: [fullscreen] Problems with mouse-edge scrolling and games
Thank you Ian for the clear use case write up (and to Artillery for progress on a great product), Florian Brandon and Glenn for discussion contributions. As Florian mentioned, we did discuss this use case in 2011 and at that time I attempted to summarize the situation in the pointer lock spec FAQ [1]. Please do read that discussion of the related 3 topics of clipping, motion while clipped, and raw data. One way to move forward on those topics is to prototype functional solutions on Windows, Mac, and Linux and illuminate a practical solution that browsers may adopt. I did an investigation in 2011 and did not find a solution. For clipping only I believe Mac was the only platform I didn't find a solution for. Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can implement the functionality, we can discuss how to express this in an API. [1] https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
Re: [fullscreen] Problems with mouse-edge scrolling and games
On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch pya...@gmail.com wrote: On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.com wrote: Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can implement the functionality, we can discuss how to express this in an API. Would using Quarz CGWarpMouseCursorPosition work where you'd clamp the passed position into the desired rectangle? https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/func/CGWarpMouseCursorPosition I believe no, because it would allow the pointer to escape the region before being warped back, permitting escape if clicked at that time as well.
Re: RfC: LCWD of Pointer Lock; deadline November 28
I also saw no comments or bugs filed. On Sat, Nov 30, 2013 at 8:09 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Vincent, All, I didn't notice any comments or bugs. Did I miss anything? If not, I'll start a CfC to publish a Candidate Recommendation. -Thanks, AB On 10/31/13 3:32 PM, ext Arthur Barstow wrote: This is a Request for Comments for the Last Call Working Draft of Pointer Lock: http://www.w3.org/TR/2013/WD-pointerlock-20131031/ If you have any comments, please send them to public-webapps @ w3.org by November 28 using a Subject: header of [pointerlock]. -Thanks, AB
Re: Testing Pointer Lock
[BCC webapps, +test-infra] Dear test infra, I've a pointer lock spec [1] which will be easiest to test with automation such as WebDriver. I haven't used WebDriver, nor testharness.js tests yet. As Tobie suggests below, I'd like to explore a WebDriver option in the w3 context. This is a long term goal to have a reasonable automatable test suite for pointer lock, I'll likely create a few manual tests in the short term. [1] http://www.w3.org/TR/pointerlock/ On Thu, Oct 3, 2013 at 6:18 PM, Tobie Langel to...@fb.com wrote: On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote: On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com(mailto: sch...@google.com) wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. That might be tested using a reftest[1]. - A user gesture is required to lock when not in fullscreen. That might be tested using a WebDriver test (we haven't agreed on a way to write or run those yet). - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) This might also be feasible using WebDriver. - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. That could be automated using WebDriver. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. If there's interest on your side to explore the WebDriver-based option, I'm happy to start a discussion on how those tests should be written in the relevant channel (public-test-in...@w3.org), but that really depends on what your main goal with this effort is (move the spec along the REC track, or improve interop) and what your timeline's like. If you want to ship the spec quickly, going the manual route with testharness.js is probably your best option. You'll always be able to revisit later (you could even do both in parallel). --tobie --- [1]: http://testthewebforward.org/docs/reftests.html
Re: [pointerlock] Seeking status and plans
On Wed, Oct 2, 2013 at 9:30 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Vincent, If any of the data for the Pointer Lock spec in [PubStatus] is not accurate, please provide corrections. Pointer Lock is no longer blocked on mozilla security review. Firefox stable now implements behavior similar to Chrome when not in full screen. I will be updating the spec and closing https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 soon. Also, if you have any new information re your plans for the spec - last published 29-May-2012 - or the spec's status with respect to being feature complete, implementation status, etc. please let us know. I will update the specification to include the constraints now implemented in Firefox and Chrome, but will leave wording allowing user agents to have additional constraints as appropriate for future contexts. I will also clarify the spec by adding reference to onpointerlockchange and onpointerlock error, and specifying that pointer lock should not be exited upon a transition in window state between fullscreen, maximized or restored. At that point I would like to publish another working draft of the specification, possibly a Last Call Working Draft. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/**webapps/wiki/PubStatushttp://www.w3.org/2008/webapps/wiki/PubStatus
Testing Pointer Lock
Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions.
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Wed, May 1, 2013 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib sch...@google.com wrote: I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec churn as fullscreen, but I think we're in a position to have both of them be cleaned up before un-prefixing. Okay. Lets kill the bubbling and define the event handlers inline. Sorry for the delay. Thanks, sounds good to me. I see and agree with your changes listed here [1]. I have modified the pointer lock spec to not bubble the events. Fullscreen still depends on HTML for iframe allowfullscreen and for HTML terminating fullscreen when navigating. Does pointer lock require something similar? Pointer lock does use the concept of the sandboxed pointer lock browsing context flag allow-pointer-lock[2], which has been included in whatwg living HTML. I'm neutral on the potential argument of defining the sandbox flag inline as well, it is mentioned referenced in the pointer lock specification. This should conclude this thread, onpointerlockchange/onpointerlockerror properties defined in the spec. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637#c10 [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-pointer-lock-browsing-context-flag
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Sat, Mar 16, 2013 at 8:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib sch...@google.com wrote: I have added onipointerlockchange and onpointerlockerror to the partial document IDL in the pointer lock specification. Webkit currently only defines these event handler attributes on document. Unless a reason is raised to add them elsewhere, I do not plan to add additional attributes elsewhere, for reasons discussed in fullscreen specification primarily regarding the confusing when releasing exiting due to an element being removed from the DOM, and confusion over multiple listener points. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html FWIW, in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 Ian argues for Window/body due to their bubbling nature. I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec churn as fullscreen, but I think we're in a position to have both of them be cleaned up before un-prefixing.
Re: Pointer lock updated with clarification of lock and focus requirements.
On Sat, Mar 16, 2013 at 7:51 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Mar 15, 2013 at 5:24 PM, Vincent Scheib sch...@google.com wrote: After discussion with Olli Pettay I have clarified portions of the pointer lock specification. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html When requesting pointer lock, this paragraph replaces previous statements regarding the target being in the DOM tree. Pointer lock must succeed only if the target is in the active document of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager. The target element and its browsing context need not be in focus. In Requirements, clarification was added that focus MAY be shifted out of a document and into others without exiting lock: The Pointer Lock API must exit the pointer lock state if the target is removed from its document, or the user agent, window, or tab loses focus. Moving focus between elements of active documents, including between browsing contexts, does not exit pointer lock. E.g. using the keyboard to move focus between contents of frames or iframes will not exit. Feedback and suggestions welcome. Why would pointer lock care about focus? Multiple browser contexts may be displayed in one window by a browser, and in most browsers pressing TAB key will move between focusable elements, such as buttons, including across browsing contexts (e.g. crossing iframe boundaries). The spec was updated the explicitly clarify that pointer lock does not care about this focus across browsing contexts. If the browsing context doesn't have focus, pointer lock may be released at the system level, but that should be transparent to the page and reestablished automatically if the user returns. The property of the user agent exiting pointer lock when the window looses focus is intentionally included in the specification to increase the ability of a user to exit pointer lock and return to the browser without being forced back into lock. They can navigate away from a page without the page able to re-capture the pointer. This is why a user gesture is required for re-entry. This will be clarified when I close https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 pending Mozilla's implementation of https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5. Pages shouldn't need to care about this. This is the same as fullscreen--obviously a page shouldn't be forced out of fullscreen if the user switches to another tab or application, unless that's the system convention (which it isn't on any platform I know of). (By the way, if a web specification finds itself talking about windows or window managers or tabs normatively, something is probably wrong. Interfaces at a higher abstraction level than browsing contexts are implementation details. Please see http://www.whatwg.org/specs/web-apps/current-work/#dom-document-hasfocusfor platform-independent language.) Hasfocus relates to the document. I suppose I can re-word to something like, all documents of all active browsing contexts which are descendants of the top most browsing context do not have focus instead of user agent tab or window loses focus. :\ yuck. -- Glenn Maynard
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
I have added onipointerlockchange and onpointerlockerror to the partial document IDL in the pointer lock specification. Webkit currently only defines these event handler attributes on document. Unless a reason is raised to add them elsewhere, I do not plan to add additional attributes elsewhere, for reasons discussed in fullscreen specification primarily regarding the confusing when releasing exiting due to an element being removed from the DOM, and confusion over multiple listener points. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html On Thu, Mar 14, 2013 at 12:05 PM, Simon Pieters sim...@opera.com wrote: On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky bzbar...@mit.edu wrote: And if so, which objects should they be on? Window? Documents? Elements? Currently event handlers are available on all of Window, Document and HTMLElement even if the relevant event just fires on one of them, so I suggest we do that. -- Simon Pieters Opera Software
Pointer lock updated with clarification of lock and focus requirements.
After discussion with Olli Pettay I have clarified portions of the pointer lock specification. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html When requesting pointer lock, this paragraph replaces previous statements regarding the target being in the DOM tree. Pointer lock must succeed only if the target is in the active document of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager. The target element and its browsing context need not be in focus. In Requirements, clarification was added that focus MAY be shifted out of a document and into others without exiting lock: The Pointer Lock API must exit the pointer lock state if the target is removed from its document, or the user agent, window, or tab loses focus. Moving focus between elements of active documents, including between browsing contexts, does not exit pointer lock. E.g. using the keyboard to move focus between contents of frames or iframes will not exit. Feedback and suggestions welcome.
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
[Including Anne Tantek due to their work on Fullscreen] The pointer lock specification intentionally mimics the fullscreen specification to provide consistency for developers, as they are similar and expected to be commonly used in the same apps. Neither specification mention event properties. Mozilla and Chrome implement document.onprefixfullscreenchange document.onprefixfullscreenerror document.onprefixpointerlockchange document.onprefixpointerlockerror Pending agreement to add properties to the fullscreen specification, I agree this should be included in the specification. On Thu, Jan 10, 2013 at 9:24 AM, Boris Zbarsky bzbar...@mit.edu wrote: And if so, which objects should they be on? Window? Documents? Elements? -Boris
Pointer Lock status. Was: pointerLock vendor prefixes, shims and usability
On Fri, Jan 4, 2013 at 4:49 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Vincent, Seeing this discussion, and noting two open [Bugz], I was wondering about the plan to get this spec to a feature complete status (and hence ready for Last Call Working Draft). Would you please provide a short status/plan for Pointer Lock spec vis-à-vis LCWD? -Thanks, AB [Bugz] https://www.w3.org/Bugs/**Public/buglist.cgi?product=** WebAppsWGcomponent=Pointer%**20Lockresolution=---list_id=**3760https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---list_id=3760 The discussion about how easily javascript shims can be created is orthogonal to the pointer lock spec. I'll leave that discussion on that thread, which I note has concluded in pointer lock has apparently already been shimmed. Of the two open issues, one [1] was already resolved (adding allow-pointer-lock to HTML). I've closed the issue. The other [2] is blocked on Mozilla's security review [3]. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18647 [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=822654
Re: [pointer-lock] pointerLockElement should be nullable in the IDL
Thanks, updated to use the nullable type. http://dvcs.w3.org/hg/pointerlock/rev/ecf0846c2f8f On Tue, Nov 27, 2012 at 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: The IDL at http://dvcs.w3.org/hg/**pointerlock/raw-file/default/** index.html#extensions-to-the-**document-interfacehttp://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#extensions-to-the-document-interfacesays: readonly attribute Element pointerLockElement; but the attribute can return null, so the type should be Element?. -Boris
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
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 modes of Fullscreen. It seems to add complexity for developers and disjoint experiences for users. If the experience is the same for users, what is the point of having the API split? If it's not the same, then there is confusion over why some pages go fullscreen in different ways. 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 it will not work correctly. On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 15, 2012, at 5:01 PM, Chris Pearce cpea...@mozilla.com 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 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? Our most likely short-term goal would be the latter (enabling capability detection) but I wouldn't take full keyboard access off the table forever. We would want the freedom to apply different security policy to that case when/if we do it though. 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. 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. 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 they would be - fullscreen Nethack?) Anyway, I'm curious what the Chrome guys think. Likewise. Cheers, Maciej
Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
For those with threaded email clients, at Arthur's suggestion I've filed an issue to track this topic. http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0040.html. On Tue, Oct 2, 2012 at 4:50 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote: Speaking from the point of view of a web developer having to use this feature. It is quite painful having to perform an end-run about failure modes that are unspecified, undocumented and a moving target. In my understanding, this is precisely the intent of a specification, to avoid such incompatibilities and headaches for developers. 1) If it is intended that additional failure modes are to be randomly introduced by vendors, then this should be made explicit in the specification. 2) If such wording is added to the specification, I don't see any residual value in the specification since any developer will have to perform the trialerror endrun repeatedly patching things up as the failure modes move, we can just skip the specification altogether. As I read through this thread, I was thinking exactly the same thing that Florian has said here. Looking forward to real feature completion ;) Rick On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib sch...@google.com wrote: I agree that pointer lock is quite useful outside of fullscreen, but before attempting to codify that in the specification I would want buy in from other browser vendors. I can appreciate an argument to remain restricted to fullscreen. Application developers can automatically escalate to requesting fullscreen upon the first pointerlockerror given the current behavior of FireFox. It's more code, but not a burdensome amount. If future abuse of the feature appears on the web, there may be other criteria used by browsers to suppress the feature. The specification states The user agent determines if pointer lock state will be entered which allows for browsers to add additional constraints. I could word that more explicitly if it would help. But my intent was specifically to allow browsers to use additional discretion. E.g. see the 'A full screen approach' in the specification's non-normative security section. Also, note that Chrome allows users to enter global suppression of the feature via the content settings preference, a override accepted similarly by the specification. Also, a small nit regarding chrome requires the pointer lock request to fail if not resulting from a user interaction target. Chrome allows pointer lock without any user gesture if requested when in fullscreen. Out of fullscreen a user gesture (click, key press) is required. See http://www.chromium.org/developers/design-documents/mouse-lock On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch pya...@gmail.com wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 10/02/2012 11:55 PM, Florian Bösch wrote: I'd like to point out that vendors are using additional failure criteria to determine if pointerlock succeeds that are not outlined in the specification. Firefox uses the fullscreen change event to determine failure and chrome requires the pointer lock request to fail if not resulting from a user interaction target. I think that Firefoxes interpretation is less useful than Chromes, But safer Also not in conformance to the specification (hence a bug). Additionally, it will make it really difficult to follow the specification since non-fullscreen mouse capture is specifically intended by the specification by not adding that failure mode *to* the specification (there's a fairly long discussion on this on the chrome ticket for pointerlock resulting in what Chrome does now). and that Chromes interpretation should be amended to the spec since it seems like a fairly good idea. I'm not yet convinced that it is safe enough. Also, it is not properly defined anywhere. So either Chrome is also implementing in conformance to the specification, or the specification is changed. Ipso facto, the specification is not complete since I don't think Chrome will drop this failure mode, and it seems like Firefox is intending to follow Chromes lead because otherwise it wouldn't be possible to implement non-fullscreen pointerlock.
Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
I agree that pointer lock is quite useful outside of fullscreen, but before attempting to codify that in the specification I would want buy in from other browser vendors. I can appreciate an argument to remain restricted to fullscreen. Application developers can automatically escalate to requesting fullscreen upon the first pointerlockerror given the current behavior of FireFox. It's more code, but not a burdensome amount. If future abuse of the feature appears on the web, there may be other criteria used by browsers to suppress the feature. The specification states The user agent determines if pointer lock state will be entered which allows for browsers to add additional constraints. I could word that more explicitly if it would help. But my intent was specifically to allow browsers to use additional discretion. E.g. see the 'A full screen approach' in the specification's non-normative security section. Also, note that Chrome allows users to enter global suppression of the feature via the content settings preference, a override accepted similarly by the specification. Also, a small nit regarding chrome requires the pointer lock request to fail if not resulting from a user interaction target. Chrome allows pointer lock without any user gesture if requested when in fullscreen. Out of fullscreen a user gesture (click, key press) is required. See http://www.chromium.org/developers/design-documents/mouse-lock On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch pya...@gmail.com wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 10/02/2012 11:55 PM, Florian Bösch wrote: I'd like to point out that vendors are using additional failure criteria to determine if pointerlock succeeds that are not outlined in the specification. Firefox uses the fullscreen change event to determine failure and chrome requires the pointer lock request to fail if not resulting from a user interaction target. I think that Firefoxes interpretation is less useful than Chromes, But safer Also not in conformance to the specification (hence a bug). Additionally, it will make it really difficult to follow the specification since non-fullscreen mouse capture is specifically intended by the specification by not adding that failure mode *to* the specification (there's a fairly long discussion on this on the chrome ticket for pointerlock resulting in what Chrome does now). and that Chromes interpretation should be amended to the spec since it seems like a fairly good idea. I'm not yet convinced that it is safe enough. Also, it is not properly defined anywhere. So either Chrome is also implementing in conformance to the specification, or the specification is changed. Ipso facto, the specification is not complete since I don't think Chrome will drop this failure mode, and it seems like Firefox is intending to follow Chromes lead because otherwise it wouldn't be possible to implement non-fullscreen pointerlock.
Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote: The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for joint WG meetings and lots of informal information sharing. As such, it can be useful to make new publications before TPAC. There is a publication blackout period around TPAC and Oct 23 is the last day to request publication before TPAC. Given our 1-week CfC for new publications, weekends, etc., Oct 15 is the last day to start a CfC to publish a document before TPAC. However, a lot of groups publish documents at this time so starting the CfC earlier is highly recommended. Scanning [PubStatus], here are some potential candidates to publish before TPAC. It would be good to re-publish our newer specs, especially if the spec has had some relatively significant changes (since FPWD) and/or it is getting some implementation/deployment: * File API - Arun can you get this spec ready for LC by October 15? * Gamepad - Scott, Ted - what's the status of the spec and its implementation? * Indexed Database API - Jonas, Eliot - what's the status of LC#1 comment processing? Is a new LC going to be necessary? * 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. * Screen Orientation - Mounir - what's the status of the spec and its implementation? * Server-sent Events - Hixie - can you give a rough guestimate on when bugs 15495 and 18796 will be fixed? (It looks to me like those are the only two bugs blocking CR.) If any other Editors want to publish a spec before TPAC, that would be great so please let us know and I'll start a CfC to publish. -Thanks, AB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
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 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. (Bugzilla reports Zarro Boogs found [2] and I didn't notice any issue/bug blocks in the latest ED). -Thanks, Art [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---
Re: [whatwg] allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
Thank you Adam, ROC, Anne. I commented on issue. On Wed, Aug 1, 2012 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren ann...@annevk.nl wrote: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838 I did not want to define new HTML features in a separate draft. So Vincent, if you want to argue for a different design, that bug would be the place I think. I do not really care either way, I just went with what roc came up with. -- http://annevankesteren.nl/
allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
[correcting Anne van Kesteren's email] On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib sch...@google.com wrote: I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? Many applications will consider they are the only users of an interface. If so, it doesn't matter much where the notifications come in. Next, developers are likely to include more than one bit of functionality on a page. E.g. a game portal with a few games that could be clicked on to go Fullscreen and or enter Pointer Lock. It's more straight forward to place listeners on each game's relevant elements, and not expect to receive cross communication from some other portion of the page. If listeners must all live on the document than application developers must write more code to track what's going on. Oh, you received an error event? Has this component recently attempted fullscreen/lock? What if you did request and you will succeed, but another component also requested on the same user gesture and that generated an error event? Application developers all must go through some additional checks to figure out if the messages were intended for them. Finally, some pages may have applications that expect to be removed from the DOM. I don't think we'd expect this very often, but developers should be able to handle it. Even if the specs didn't dispatch change events to the document the developers could detect that the element was removed and stop whatever they were doing with them.
Fullscreen events dispatched to elements
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. The Fullscreen specification calls for events to be dispatched to the document, but the WebKit implementation dispatches fullscreenchange and fullscreenerror events to the context element (and they bubble to the document). 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? There is a related thread started on May 11th 2011 by Jer Noble where he proposes dispatching to the elements, but the thread moves onto other topics. I don't see a resolution regarding dispatching to elements other than early general approval by Robert O'Callahan. [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: CfC Re: Charter addition proposal: screen orientation lock
Mounir, I ran into the same confusion regarding how does the API expose locking?. May I suggest that you explicitly state in the abstract that the API is pending? On Wed, Feb 15, 2012 at 8:34 AM, Paul Bakaus pbak...@zynga.com wrote: Cool, thanks for the update! Am 15.02.12 13:21 schrieb Mounir Lamouri unter mou...@lamouri.fr: On 02/15/2012 04:29 AM, Tobie Langel wrote: In the Screen Orientation API draft, I don't see any references to locking. Is this by design? It's in the abstract: The Screen Orientation API's goal is to provide an interface for web applications to be able to read the screen orientation state, to be informed when this state changes and to be able to lock the screen orientation to a specific state. --http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html I only wrote the reading part for the moment because there are still some discussions in Mozilla's WebAPI mailing list [1] about the locking part. When the specification draft will be complete, I will send a message here. [1] https://www.mozilla.org/about/forums/#dev-webapi -- Mounir
Re: Overhauling Pointer Lock (was Mouse Lock) to FullScreen API pattern
Pointer lock spec[1] has been updated as I described, with the exception of allowpointerlock which still needs to be added. http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html Feedback welcome. On Fri, Jan 27, 2012 at 9:06 PM, Vincent Scheib sch...@google.com wrote: The spec for Pointer Lock has been moved[1]. It was also renamed from the previous Mouse Lock. While landing the initial implementation in WebKit Darin Fisher pointed out that the Fullscreen API[2] had strong overlap with the pointer lock spec in dealing with entering and exiting a state targeting a particular element. To simplify the web platform, and because these features will often be used together, I'm planning on revamping the pointer lock specification to match the Fullscreen spec as closely as possible. Specifically, using: partial interface Element { void requestPointerLock(); }; partial interface Document { readonly attribute boolean pointerLockEnabled; readonly attribute Element pointerLockElement; void exitPointerLock(); }; Events: pointerlockerror, pointerlockchange iframe attribute: allowpointerlock The previous MouseEvent addition of movement is unchanged: partial interface MouseEvent { readonly attribute long movementX; readonly attribute long movementY; }; Stakeholders of the Mozilla/Firefox implementation have indicated support for this transition. Comments / Feedback welcome! [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: Overhauling Pointer Lock (was Mouse Lock) to FullScreen API pattern
On Tue, Feb 7, 2012 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 7, 2012 at 9:58 AM, Vincent Scheib sch...@google.com wrote: Pointer lock spec[1] has been updated as I described, with the exception of allowpointerlock which still needs to be added. http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html Feedback welcome. What's the purpose of the 'pointerLockEnabled' property? It seems like null-checking pointerLockElement provides exactly the same information. / Jonas Error on my part. Once incorporating the iframe permission attribute this should instead return true if the context and all ancestor contexts have permision to lock. e.g. from Fullscreen, The fullscreenEnabled attribute must return true if the context object and all ancestor browsing context's documents have their fullscreen enabled flag set, or false otherwise. I've removed it.
Overhauling Pointer Lock (was Mouse Lock) to FullScreen API pattern
The spec for Pointer Lock has been moved[1]. It was also renamed from the previous Mouse Lock. While landing the initial implementation in WebKit Darin Fisher pointed out that the Fullscreen API[2] had strong overlap with the pointer lock spec in dealing with entering and exiting a state targeting a particular element. To simplify the web platform, and because these features will often be used together, I'm planning on revamping the pointer lock specification to match the Fullscreen spec as closely as possible. Specifically, using: partial interface Element { void requestPointerLock(); }; partial interface Document { readonly attribute boolean pointerLockEnabled; readonly attribute Element pointerLockElement; void exitPointerLock(); }; Events: pointerlockerror, pointerlockchange iframe attribute: allowpointerlock The previous MouseEvent addition of movement is unchanged: partial interface MouseEvent { readonly attribute long movementX; readonly attribute long movementY; }; Stakeholders of the Mozilla/Firefox implementation have indicated support for this transition. Comments / Feedback welcome! [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [Pointer Lock] Few comments
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay olli.pet...@helsinki.fiwrote: Hi all, few comments about the API (1) currently http://dvcs.w3.org/hg/**webevents/raw-file/default/** mouse-lock.htmlhttp://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.htmluses VoidCallback which isn't defined anywhere. I guess there should be something like void lock (in Element target, optional in LockSuccessCallback successCallback, optional in LockErrorCallback failureCallback); [Callback,NoInterfaceObject] interface LockSuccessCallback { void pointerLockSuccess(); }; [Callback,NoInterfaceObject] interface LockErrorCallback { void pointerLockFailure(); }; Or if the new proposed callback syntax is used: callback LockSuccessCallback = void pointerLockSuccess(); callback LockErrorCallback = void pointerLockFailure(); I used the concept of VoidCallback from other implemented specs. Are there any issues with it other than that the spec should define VoidCallback? e.g. http://www.w3.org/TR/file-system-api/#the-voidcallback-interface http://www.w3.org/TR/2009/WD-DataCache-20091029/#VoidCallback (2) If another element is locked a user agent must transfer the mouse lock to the new target and call the pointerlocklost callback for the previous target. There is no such thing as 'pointerlocklost callback' Spec typo, it should read pointerlocklost event. (3) Mouse lock must succeed only if the window is in focus and the user-agent is the active application of the operating system What window? window object as in web page? Or OS level window? What if lock is called in some iframe? The intent is the user-agent window and tab (if tabbed UA). Other than UA security considerations, I propose there be no difference between lock calls from a top level document or an iframe. Suggestions welcome for a way to make this more clear than rewriting to be, ... succeed only if the user-agent window (and tab, if a tabbed browser) is in focus ... (4) If the target is removed from the DOM tree after mouse lock is entered then mouse lock will be lost. Should 'pointerlocklost' event be dispatched? I'm not yet certain about the implementation practicalities, and need to research more, but is seems we have these options: a- don't send the event b- send to the element after it has been detached c- send to the nearest ancestor of the element that remains in the tree d- send to the element before it is detached
Re: Mouse Lock
WebEvents WG is taking up this spec. I've created a new Mouse Lock thread on public-webevents: http://lists.w3.org/Archives/Public/public-webevents/2011OctDec/0066.html
Re: Mouse Lock
WebEvents WG has proposed a charter revision that includes Mouse Lock: http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0087.html Also, Minor update to spec: 0.71, 2011-09-27 Preventing malicious 'click jacking' behavior has been curtailed by requiring the target of mouse lock events to be in the top-level origin (as the call to lockMouse() must also be). This replaces previous text requiring mouse lock events to not be considered user gestures. This was instigated by comments on webkit-dev https://lists.webkit.org/pipermail/webkit-dev/2011-September/018028.html On Mon, Sep 12, 2011 at 2:11 PM, Vincent Scheib sch...@google.com wrote: I've updated the draft spec http://goo.gl/9G8pd with these points. - Removed Touch related components to simplify initial version of specification and because they do not add the same level of new application capability as mouse related events. - MouseLockable Interface moved from element to document, mouselock takes target as parameter, mouseLocked returns current target element. - movementX/Y behavior when system cursor reenters window specified as zeros - lockMouse must be called from the same origin as the top level document - Cases of target element not being in DOM tree specified to fail or exit lock - Mouse user gestures suppressed while under mouse lock - Client and screen coordinates when under lock report the last value they had when lock was entered. Clarification on events that should and should not fire when under mouse lock. - Added example Example handling failure to lock - Use case rewrite: View-port panning by moving a mouse cursor against the bounds of a view-port. - Merged use cases Free three dimensional model rotation Move layers of information without bound limits - Added FAQ Why bundle all functionality (hiding cursor, providing mouse deltas) instead of using CSS to hide the cursor, always providing delta values, and offering an API to restrict the cursor movement to a portion of the webpage? - Added FAQ Why modify MouseEvent and reuse existing mouse events instead of creating a mousedelta event? - Added FAQ Why separate targets for mouse events under mouse lock and keyboard input focus? On Fri, Aug 26, 2011 at 4:56 PM, Vincent Scheib sch...@google.com wrote: -- What if target is removed from DOM, or is not currently in DOM? -- Additional issues from Olli Pettay on w3 bug. I believe mouse lock should fail to acquire if the target is not in the DOM tree, and should be exited if the target of an existing lock is removed from the tree. -- Are user gestures generated while under mouse lock? -- From a security point of view, should we sanitize the events generated when in mouse lock (click, down, up, ...) to be 'synthetic' and not 'user gestures'? E.g. in Chrome I believe you can only pop up new windows with window.open from script code triggered by a user gesture event. If we don't, and assuming security model allowing only mouse lock for DOM within top level document origin, then a page could direct user gesture events to any DOM element in their origin they wanted. That may be used for a form of 'click jacking'. On Thu, Aug 25, 2011 at 5:54 PM, Vincent Scheib sch...@google.comwrote: Continuing the discussion of some of the open issues I'm aware of: -- If MouseEvent types are returned under mouse lock, what should .clientX/Y and screenX/Y be? -- Spec as drafted states they should be the center of the target element. That's likely a poor idea, as discussed, and a better solution is to freeze .clientX/Y and screenX/Y to whatever their last value from the user agent was. (Pending feedback, I will update spec to state that .clientX/Y .screenX/Y will report the same constant values of the last known cursor position just as mouse lock was entered. This will also be the location the system cursor will be placed at when mouse lock is exited) -- Modify MouseEvent, or a new type returned by new mouse events? -- Spec as drafted now has simply added .movementX/Y data members to the MouseEvent type which is returned by mouse events: click, mousedown, mouseup, mouseover, mousemove, mouseout. No new mouse event types are introduced. Several, including Glenn Maynard, Robert O'Callahan have brought up points against this, suggesting different events and types. Let me enumerate options and my perceived pro/cons: Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 1. minimal change to existing events and types pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). pro 3. event handling code that can operate both with and without
Proposal to add Mouse Lock to the Web Events Working Group
A Mouse Lock API has been under discussion on the W3 public-webapps list Mouse Lock[1] and earlier Mouse Capture for Canvas[2]. The primary goal is to enable use cases such as first person perspective 3D applications. This is done by providing scripted access to mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. I have been working to formalize the discussions into a draft specification[3]. I propose that the Web Events Working Group consider adoption of Mouse Lock for formal specification. Cheers, -Vince 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 3. http://goo.gl/9G8pd Additional discussions: W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754
Re: Mouse Lock
But do you agree with me that post ballistics, accelerated and low resolution is exactly what you don't want for most use cases? Why should it not be possible to specify the units I described in my last mail: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0978.html. That email describes computing distance traveled of input device presuming DPI, sampling rate, and a sample's delta data. DPI is unknown (unless I'm not finding it in APIs e.g. around http://msdn.microsoft.com/en-us/library/ms645589.aspx). I believe first developers seek a specifiable solution that will provide a consistent application experience on all platforms and API implementations. I further believe that post ballistics data will satisfy most developers and users; I have asked some e.g. Unity developers about their implementations and needs, and checked source of other games (e.g. SDL library). Finally, I believe that it is worthwhile to consider adding some rawer form of the input data if possible in a v2 implementation and or spec. Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). Purely a convenience is incorrect. Once the mouse cursor reaches the edge of the screen, you can no longer detect motion in that direction by examining the cursor position. That's why you either need to warp the mouse or use raw input events. (Remember, mousemove events are still sent when the mouse is outside of the window, if the user is dragging.) Sorry, some confusion here. This topic Modify MouseEvent, or a new type returned by new mouse events? presumes the hide cursor and warp method, as do all other sections in my recent summary except section Provide mouse deltas without hiding the cursor, alternatively provide a bounding rectangle for mouse. This section is trying to lay out the pros/cons of where to put movement data. The Option A is to provide movementX/Y when locked and unlocked. When locked, the cursor disappears and movement data is provided without limit. When unlocked the mouse events continue to contain that data member and values are provided with best effort. The system cursor exists and mouse events are not available when the cursor is not over the window (unless the mouse is captured). Movement values will stop when the cursor hits a screen edge. The movement members then become only a convenience because javascript code can compute the same values by storing last known positions of screenX/Y and tracking motion with mousemove mouseover. MouseEvent to include movementX/Y valid regardles of mouse lock state I don't think it's possible to both 1: use the same units as the cursor (screen pixels) and 2: get this information when the cursor is visible. If you use the raw APIs (eg. WM_INPUT) Correct, the proposal is NOT to use raw APIs as described above. You forgot a con with this approach: There's no way of exposing functionality of high-res mice. You can only detect mouse motion when it's far enough to cause the (unseen) cursor to move a pixel, because you're reporting motion in terms of cursor movement, rather than the higher-resolution data provided by the device. You're also forced to receive mouse acceleration and I believe axis locking (improve pointer precision in Windows), which may not always be wanted for first-person games. (You also can't expose the ability of modern mice to report at higher rates, eg. 1khz, for the same reason; I'm personally ambivalent about this since I don't have any use cases for it, but others may.) I'm deferring consideration for higher resolution mice data and sampling frequency to a future version of this specification. This was discussed some in Provide mouse deltas without hiding the cursor, alternatively provide a bounding rectangle for mouse. But a summary of my position is that: - Specification is difficult and may not be possible. - Implementation is more complex and doesn't seem justified yet. - Graceful addition of more 'raw' data and higher sampling frequencies is possible. I'm not saying We shouldn't implement raw data, but I am saying we should defer it. I'm happy to review any prototype patches to the chromium/webkit projects that answer these issues. New mouse events created with unique names for click, down, up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. I'm confused: was this suggested? I suggested a single event fired for delta movement, eg. mousedelta, but of course there wouldn't be separate events for clicks, too; clicks are orthogonal to motion. (I'm confused that you dismissed
Re: Mouse Lock
-- What if target is removed from DOM, or is not currently in DOM? -- Additional issues from Olli Pettay on w3 bug. I believe mouse lock should fail to acquire if the target is not in the DOM tree, and should be exited if the target of an existing lock is removed from the tree. -- Are user gestures generated while under mouse lock? -- From a security point of view, should we sanitize the events generated when in mouse lock (click, down, up, ...) to be 'synthetic' and not 'user gestures'? E.g. in Chrome I believe you can only pop up new windows with window.open from script code triggered by a user gesture event. If we don't, and assuming security model allowing only mouse lock for DOM within top level document origin, then a page could direct user gesture events to any DOM element in their origin they wanted. That may be used for a form of 'click jacking'. On Thu, Aug 25, 2011 at 5:54 PM, Vincent Scheib sch...@google.com wrote: Continuing the discussion of some of the open issues I'm aware of: -- If MouseEvent types are returned under mouse lock, what should .clientX/Y and screenX/Y be? -- Spec as drafted states they should be the center of the target element. That's likely a poor idea, as discussed, and a better solution is to freeze .clientX/Y and screenX/Y to whatever their last value from the user agent was. (Pending feedback, I will update spec to state that .clientX/Y .screenX/Y will report the same constant values of the last known cursor position just as mouse lock was entered. This will also be the location the system cursor will be placed at when mouse lock is exited) -- Modify MouseEvent, or a new type returned by new mouse events? -- Spec as drafted now has simply added .movementX/Y data members to the MouseEvent type which is returned by mouse events: click, mousedown, mouseup, mouseover, mousemove, mouseout. No new mouse event types are introduced. Several, including Glenn Maynard, Robert O'Callahan have brought up points against this, suggesting different events and types. Let me enumerate options and my perceived pro/cons: Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 1. minimal change to existing events and types pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). pro 3. event handling code that can operate both with and without mouse lock being acquired can do so easily using the same functions and taking the same MouseEvent data type input. e.g. rotateView(mouse_event) could be called from a mousemove event regardless of mouse lock state and still use .movementX/Y. con 1. When under mouse lock, clientX/Y screenX/Y will not offer any useful data - or worse implementations may not follow spec and provide misleading data of the actual hidden cursor location. con 2. Not all mouse events using MouseEvent are appropriate, mouseover and mouseout should be suppressed. Glen continued that it is probably cleaner to stop firing *all* mouse movement events entirely, as if the mouse isn't moving, and to use a separate mousedelta event when locked which only has deltaX and deltaY. Robert reiterated that point. Option B: make no use of or modification to any existing mouse event or the MouseEvent type. New mouse events created with unique names for click, down, up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. New events return a MouseLockEvent type derived from UIEvent that contains movementX/Y, ctrlKey, shiftKey, altKey, metaKey, button. The events and data types are completely mutually exclusive based on the state of mouse lock. pro 1. (dual of Option A con 1): clientX/Y screenX/Y do not exist under mouse lock. pro 2. (dual of Option A pro 3): Functions designed specifically to operate only under mouse lock, or only when not under mouse lock, are only triggered when appropriate. con 1. (dual of Option A pro 1): Larger change, introducing 4 new events and a new return type. con 2. (dual of Option A pro 2): movementX/Y must be calculated manually by apps when not under lock. Some hybrid could be considered, e.g. only make a new mouselockmove event but reuse the click/down/up events. I don't think that hybrid is worth discussing. My opinion: - Option A con 1 (.client .screen not useful, could be wrong): I don't perceive much damage here, and if implementation are making mistakes much more could go wrong elsewhere, but they don't get new data even with faulty client and screen data. - Option A con 2 (not all events returning MouseEvent are appropriate in mouse lock) isn't substantial... 4 of the events are and they happen to share a MouseEvent type
Re: Mouse Lock
Continuing the discussion of some of the open issues I'm aware of: -- If MouseEvent types are returned under mouse lock, what should .clientX/Y and screenX/Y be? -- Spec as drafted states they should be the center of the target element. That's likely a poor idea, as discussed, and a better solution is to freeze .clientX/Y and screenX/Y to whatever their last value from the user agent was. (Pending feedback, I will update spec to state that .clientX/Y .screenX/Y will report the same constant values of the last known cursor position just as mouse lock was entered. This will also be the location the system cursor will be placed at when mouse lock is exited) -- Modify MouseEvent, or a new type returned by new mouse events? -- Spec as drafted now has simply added .movementX/Y data members to the MouseEvent type which is returned by mouse events: click, mousedown, mouseup, mouseover, mousemove, mouseout. No new mouse event types are introduced. Several, including Glenn Maynard, Robert O'Callahan have brought up points against this, suggesting different events and types. Let me enumerate options and my perceived pro/cons: Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 1. minimal change to existing events and types pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). pro 3. event handling code that can operate both with and without mouse lock being acquired can do so easily using the same functions and taking the same MouseEvent data type input. e.g. rotateView(mouse_event) could be called from a mousemove event regardless of mouse lock state and still use .movementX/Y. con 1. When under mouse lock, clientX/Y screenX/Y will not offer any useful data - or worse implementations may not follow spec and provide misleading data of the actual hidden cursor location. con 2. Not all mouse events using MouseEvent are appropriate, mouseover and mouseout should be suppressed. Glen continued that it is probably cleaner to stop firing *all* mouse movement events entirely, as if the mouse isn't moving, and to use a separate mousedelta event when locked which only has deltaX and deltaY. Robert reiterated that point. Option B: make no use of or modification to any existing mouse event or the MouseEvent type. New mouse events created with unique names for click, down, up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. New events return a MouseLockEvent type derived from UIEvent that contains movementX/Y, ctrlKey, shiftKey, altKey, metaKey, button. The events and data types are completely mutually exclusive based on the state of mouse lock. pro 1. (dual of Option A con 1): clientX/Y screenX/Y do not exist under mouse lock. pro 2. (dual of Option A pro 3): Functions designed specifically to operate only under mouse lock, or only when not under mouse lock, are only triggered when appropriate. con 1. (dual of Option A pro 1): Larger change, introducing 4 new events and a new return type. con 2. (dual of Option A pro 2): movementX/Y must be calculated manually by apps when not under lock. Some hybrid could be considered, e.g. only make a new mouselockmove event but reuse the click/down/up events. I don't think that hybrid is worth discussing. My opinion: - Option A con 1 (.client .screen not useful, could be wrong): I don't perceive much damage here, and if implementation are making mistakes much more could go wrong elsewhere, but they don't get new data even with faulty client and screen data. - Option A con 2 (not all events returning MouseEvent are appropriate in mouse lock) isn't substantial... 4 of the events are and they happen to share a MouseEvent type. - I see no logical argument leading us to one or the other option. I'd prefer the minimal change, the convenience of code that can use the same MouseEvent structure, and .movementX/Y even when not in mouse lock. (Pending feedback, I will leave spec at Option A but add clarification about e.g. mouseover/mouseout not being called) -- Separate targets for keyboard and mouse locked events? -- Robert: ... is there a need for mouse-lock motion events to go to one element while keyboard input goes elsewhere? ... I'm asking whether we can reuse the existing notion of the currently focused element and send mouse events to that element while the mouse is locked. I argue yes, there's a good cause for mouse events to a different target than keyboard input. Status quo enables typing into an input field while mousemove events are sent to different targets the mouse happens to be moving over. In mouse lock, consider a game with a 3D viewport controlled by mouse and a chat window with the active keyboard
Re: Mouse Lock
Re Rob: Is there a need to provide mouse-locking on a per-element basis? It seems to me it would be enough for mouse-locking to be per-DOM-window (or per-DOM-document) and deliver events to the focused element. This simplifies the model a little bit by not having to define new state for the mouse-locked element. Or is there a need for mouse-lock motion events to go to one element while keyboard input goes elsewhere? I may need to clarify the specification to state that there is only a single state of mouse lock global to the user agent. You may be suggesting that the MouseLockable interface be added to only the window and not to all elements? An argument was made that multiple elements may attempt a mouseLock, especially in pages composing / aggregating content. If so, it would be undesirable for an unlockMouse() call on one element to disrupt a lock held by another element. I will update the spec to explain that decision. If you were suggesting something else, I didn't follow you. As was suggested earlier in this thread, I think given we're not displaying the normal mouse cursor and in fact warping the system mouse cursor to the center of the screen in some implementations, we shouldn't deliver normal mouse-move events. Instead, while mouselock is active, we should deliver a new kind of mouse motion event, which carries the delta properties. If you do that, then hopefully you don't need a failure or success callback. Your app should just be able to handle both kinds of mouse motion events. The argument is that mouse handling code can be simplified by always handling the same MouseEvent structures. The six modifier key and button state members and event target are still desired. When not under lock the movement members are still useful - and are tedious recreate by adding last position and edge case handling in mouseleave/enter. The success or failure events are desired to be once per call to lock, for appropriate application response. Triggering that response logic on every mouse event, or detecting the edge of that signal seems more complicated. The callbacks are also low cost, they can be inline anonymous functions or references.. they don't take special event handler registration. What am I missing in the value of having new event types? I'm not really sure how touch events fit into this. Unlike mouse events, touch events always correspond to a position on the screen, so the delta information isn't as useful. (Or do some platforms detect touches outside the screen?) Maybe the only thing you need to do for touch events is to capture them to the focused element. The motivation for touch events is to make capturing to a specific element easy, including any other window content out of an apps control (e.g. if embedded via iframe) and or any user agent UI that disables its interaction when in mouse lock to offer a better app experience. In many of your use cases, it's OK to automatically release the mouse-lock on mouse-up. If you automatically release on mouse-up, the security issues are far less serious. So I think it would be a good idea to allow applications to accept that behavior via the API. You mean you'd prefer the API have an option specified in lockMouse(...) to cause the mouse to be automatically unlocked when a mouse button is let up if the lock occurred during an event for that button being pressed? Under current API draft an application specifies that with a call to unlockMouse at a button up event. I'm hesitant to add it, since it seems relevant only for the lower priority use cases. The killer use case here is first person controls or full mouse control applications. The mouse capture API satisfies most of the use cases you're referring to, with the only limitation being loss of movement data when the cursor hits a screen edge. I don't think we should complicate this API for those nitch use cases when the functionality is available to them in this API without great effort. A lot of this would be much simpler if we could somehow get mouse delta information from all platforms (Windows!) without having to warp the cursor :-(. Has research definitively ruled out achieving that by any combination of hacks? Rob Deltas alone don't satisfy the key use cases. We must prevent errant clicks. Re: Klaas Heidstra You actually can get mouse delta info in windows using raw WM_INPUT data see: http://msdn.microsoft.com/en-us/library/ee418864(VS.85).aspx. This is also the only way to take advantage of 400dpi mice, which is useful for FPS games. Thanks for implementation tip! As for mouse locking isn't that a completely distinct feature from getting mouse delta information? For example in full-screen mode (and only using one screen) there is no need for mouse lock when you always can get mouse delta (because the mouse can't leave the screen). It is the combination of mouse capture, hidden cursor, deltas being provided with no limits of screen
Re: Mouse Lock
And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? From the draft spec: Touch devices may also choose to reserve a portion of the touch interface for an unlock gesture. Mouse lock seems irrelevant on a touchscreen... I've added clarification to the draft spec in the use case section, Touch screen device input All the application use cases are relevant on touch screen devices as well. A user should be permitted to make large gestures that are interpreted as movement deltas, without concern over the absolute positions of the touch points. Other UI elements from the user agent and system should be suppressed while under mouse lock. Absolute position of touch points should always be available, unlike mouse input where the concept of the cursor is removed. On a touch screen the absolute positions will always be relevant. Devices with no keyboard must provide escape from lock via either hard buttons or reserved screen space for an escape gesture.
Re: Mouse Lock
John Villar and I have produced a draft specification: https://docs.google.com/document/d/1uV4uDVIe9-8XdVndW8nNGWBfqn9ieeop-5TRfScOG_o/edit?hl=en_USauthkey=CM-dw7QG Some additional notes included in that draft not yet discussed here: - .deltaX conflicts with WheelEvent, I've used .movementX/Y instead unless we feel DOM L3 should be modified. - I've omitted the call of mouselocklost at a page close or ‘onbeforeunload’, as I can not determine a use case that benefits from it. - I've omitted the suggestion of cancelLock on a bubbling MouseEvent - as it is not needed, .target.unlockMouse() can be called.
Re: Mouse Lock
A range of security methods have been discussed. Please read the thread in detail if this summary is too succinct: The Security concern is that of the user agent hiding the mouse and not letting it be used normally due to malicious code on a web site. Thus, user agents must address this issue. No other security issue has been raised. A User agent has a large number of options to gauge user intent, and may use a combination of these techniques to avoid user frustration: prompt user before lock, is page full screen, require user gesture, avoid immediate relock, only lock on a forground page/tab in focus, per-domain permissions, installed application permissions, persistent instructional message to user on how to unlock, ESC key (or others) always unlocks. On Sat, Jun 18, 2011 at 11:38 PM, Adam Barth w...@adambarth.com wrote: I'm sorry that I didn't follow the earlier thread. What is the security model for mouse lock? (Please feel free to point me to a message in the archive if this has already been discussed.) Thanks, Adam On Thu, Jun 16, 2011 at 3:21 PM, Vincent Scheib sch...@google.com wrote: [Building on the Mouse Capture for Canvas thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 ] I'm working on an implementation of mouse lock in Chrome, and would appreciate collaboration on refinement of the spec proposal. Hopefully webapps is willing to pick up this spec work? I'm up for helping write the draft. Some updates from Sirisian's Comment 12 on the w3 bug (http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c12): - We shouldn't need events for success/failure to obtain lock, those can be callbacks similar to geolocation API: (http://dev.w3.org/geo/api/spec-source.html#geolocation_interface). My short summary is then: - 2 new methods on an element to enter and exit mouse lock. Two callbacks on the entering call provide notification of success or failure. - Mousemove event gains .deltaX .deltaY members, always valid, not just during mouse lock. - Elements have an event to detect when mouseLock is lost. Example x = document.getElementById(x); x.addEventListener(mousemove, mouseMove); x.addEventListener(mouseLockLost, mouseLockLost); x.lockMouse( function() { console.log(Locked.); }, function() { console.log(Lock rejected.); } ); function mouseMove(e) { console.log(e.deltaX + , + e.deltaY); } function mouseLockLost(e) { console.log(Lost lock.); }
Mouse Lock
[Building on the Mouse Capture for Canvas thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 ] I'm working on an implementation of mouse lock in Chrome, and would appreciate collaboration on refinement of the spec proposal. Hopefully webapps is willing to pick up this spec work? I'm up for helping write the draft. Some updates from Sirisian's Comment 12 on the w3 bug ( http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c12): - We shouldn't need events for success/failure to obtain lock, those can be callbacks similar to geolocation API: ( http://dev.w3.org/geo/api/spec-source.html#geolocation_interface). My short summary is then: - 2 new methods on an element to enter and exit mouse lock. Two callbacks on the entering call provide notification of success or failure. - Mousemove event gains .deltaX .deltaY members, always valid, not just during mouse lock. - Elements have an event to detect when mouseLock is lost. Example x = document.getElementById(x); x.addEventListener(mousemove, mouseMove); x.addEventListener(mouseLockLost, mouseLockLost); x.lockMouse( function() { console.log(Locked.); }, function() { console.log(Lock rejected.); } ); function mouseMove(e) { console.log(e.deltaX + , + e.deltaY); } function mouseLockLost(e) { console.log(Lost lock.); }