from:"Vincent Scheib"

Re: CFC: Republish Pointer Lock as CR

2016-06-20 Thread Vincent Scheib

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

2016-06-16 Thread Vincent Scheib

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

2016-06-16 Thread Vincent Scheib

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 Barrell 
wrote:

> 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

2015-11-01 Thread Vincent Scheib

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

2015-10-29 Thread Vincent Scheib

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

2015-10-23 Thread Vincent Scheib

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

2015-03-31 Thread Vincent Scheib

 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

2015-02-26 Thread Vincent Scheib

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

2015-01-13 Thread Vincent Scheib

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

2015-01-09 Thread Vincent Scheib

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

2014-12-04 Thread Vincent Scheib

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

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

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

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

If I press ctrl-w/cmd-w (close window/tab), 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

2014-10-27 Thread Vincent Scheib

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

2014-09-04 Thread Vincent Scheib

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

2014-07-30 Thread Vincent Scheib

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

2014-04-03 Thread Vincent Scheib

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

2014-03-14 Thread Vincent Scheib

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

2014-02-24 Thread Vincent Scheib

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

2014-02-24 Thread Vincent Scheib

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

2013-11-30 Thread Vincent Scheib

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

2013-10-04 Thread Vincent Scheib

[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

2013-10-03 Thread Vincent Scheib

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

2013-10-03 Thread Vincent Scheib

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

2013-05-01 Thread Vincent Scheib

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

2013-04-11 Thread Vincent Scheib

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.

2013-03-18 Thread Vincent Scheib

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

2013-03-15 Thread Vincent Scheib

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.

2013-03-15 Thread Vincent Scheib

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

2013-01-10 Thread Vincent Scheib

[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

2013-01-04 Thread Vincent Scheib

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

2012-11-27 Thread Vincent Scheib

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)

2012-10-16 Thread Vincent Scheib

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]

2012-10-05 Thread Vincent Scheib

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]

2012-10-02 Thread Vincent Scheib

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

2012-09-26 Thread Vincent Scheib

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]

2012-09-26 Thread Vincent Scheib

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

2012-08-01 Thread Vincent Scheib

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

2012-07-31 Thread Vincent Scheib

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

2012-07-31 Thread Vincent Scheib

[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

2012-06-05 Thread Vincent Scheib

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

2012-06-01 Thread Vincent Scheib

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

2012-02-15 Thread Vincent Scheib

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

2012-02-07 Thread Vincent Scheib

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

2012-02-07 Thread Vincent Scheib

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

2012-01-27 Thread Vincent Scheib

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

2011-12-15 Thread Vincent Scheib

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

2011-10-19 Thread Vincent Scheib

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

2011-09-27 Thread Vincent Scheib

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

2011-09-15 Thread Vincent Scheib

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

2011-08-29 Thread Vincent Scheib


 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

2011-08-26 Thread Vincent Scheib

-- 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

2011-08-25 Thread Vincent Scheib

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

2011-08-11 Thread Vincent Scheib

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

2011-06-24 Thread Vincent Scheib


 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

2011-06-22 Thread Vincent Scheib

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

2011-06-20 Thread Vincent Scheib

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

2011-06-18 Thread Vincent Scheib

[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.); }

56 matches

Mail list logo