https://www.w3.org/Bugs/Public/show_bug.cgi?id=9557
Travis Leithead [MSFT] tra...@microsoft.com changed:
What|Removed |Added
Keywords|
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
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
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.
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
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
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
Hi Vincent, All - given there were no negative comments regarding
Vincent's proposal, Doug and I will work toward updating WebEvents'
charter to add the Mouse Lock API.
Additionally, as indicated in [1], we will also work toward adding the
Gamepad API [2] (formerly know as the Joystick API
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
, and up events are needed. The
current events use the MouseEvent type. I believe that for the same reason
mousedown includes more context than just the mouse button was pressed
that the mouse lock equivalent would too. Thus, the mouse lock version of
click, down, and up events should contain
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
/Public/public-webapps/2011JulSep/0978.html.
2011/8/26 Vincent Scheib sch...@google.com
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
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
-- 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
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
mouse lock is enabled clientX,
clientY, screenX, and screenY must hold constant values as if the mouse were
located at the center of the mouse lock target element I chose this to
pick something concrete, but not all zeros which may be used as magic values
in JS code, etc. I'm not strong
You could constrain the mouse cursor on linux using a combination of
XQueryPointer and XWarpPointer. By moving the cursor when it hits the edge
of an element.
The same solution could be used for Mac where there also doesn't seem to be
a direct method for constraining the mouse cursor. When
. 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
On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
If your implementation had to warp the mouse cursor on Windows to get
accurate delta information, the mouse position in the existing mouse
On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
If your implementation had to warp the mouse cursor on Windows to
On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote:
If we expose delta information in all mouse events, which seems like
it
On Fri, Aug 12, 2011 at 2:12 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 12, 2011 at 3:14 PM, Jonas Sicking jo...@sicking.cc wrote:
And if the user doesn't approve the lock you do what? Not let them
play your game?
Maybe. It really is impossible to play a game with a control scheme
based on WASD+mouselook if you can't get a lock.
Alternately, you can
On Fri, Aug 12, 2011 at 7:50 PM, Vincent Scheib sch...@google.com wrote:
BTW, draft spec currently states, When mouse lock is enabled clientX,
clientY, screenX, and screenY must hold constant values as if the mouse were
located at the center of the mouse lock target element I chose
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).
The only problem that remains is when in multi-screen and/or
non-full-screen-mode, the mouse
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
. 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
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?
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
On Mon, Jun 27, 2011 at 6:17 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jun 27, 2011 at 8:59 PM, Gregg Tavares (wrk) g...@google.comwrote:
As far as I know if a game wants to limit movement of the mouse inside a
window they just mouselock and display their own mouse pointer. The original
On Tue, Jun 28, 2011 at 3:54 AM, Gregg Tavares (wrk) g...@google.comwrote:
I beg to differ. Nearly every game that has a mouse renders a mouse cursor
manually. At least all the ones I've played. I quick search on youtube for
rts gameplay shows this is true.
I've seen plenty of both; drawing
On Fri, Jun 24, 2011 at 10:58 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Wed, Jun 22, 2011 at 5:20 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor
simetrical+...@gmail.com
wrote:
There's a middle ground here: you can lock the mouse to
On Mon, Jun 27, 2011 at 8:59 PM, Gregg Tavares (wrk) g...@google.comwrote:
As far as I know if a game wants to limit movement of the mouse inside a
window they just mouselock and display their own mouse pointer. The original
is hidden and their pointer logic uses the deltas to move their
the case that a user needs an ability to escape from the
mouse lock context,
and to have one which lies outside of any processing handled by the
untrusted scripting environment.
The *AG practices are always the first to document these needs.
Requiring keyboard for something that locks a mouse
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
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
On Wed, Jun 22, 2011 at 5:20 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor simetrical+...@gmail.com
wrote:
There's a middle ground here: you can lock the mouse to the window,
but not completely. That is, if the user moves the mouse to the edge,
it
And what if the device in question is just a touchscreen with no
keyboard, mouse or hardware buttons?
On 6/20/11, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
The use-case
timeless,
I agree, it'd be nice to know. I'd really like to see this put toward
the AG (Accessibility Guidelines)
people, as they're the ones who follow this kind of things.
It's absolutely the case that a user needs an ability to escape from the
mouse lock context,
and to have one which
doesn't make sense when there's
no cursor. The mouse no longer has a position onscreen; mouse lock
essentially turns it into a delta-based input device.
(FWIW, I've always found the top-edge mechanic used by browsers to exit
fullscreen to be a bad case of best we could think of. It interferes
badly
On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Mon, Jun 20, 2011 at 1:48 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
A model which I suggested privately, and which I believe others have
suggested publicly, is this:
1. While fullscreen is enabled, you
On Wed, Jun 22, 2011 at 2:54 AM, Glenn Maynard gl...@zewt.org wrote:
Unrelated, another detail: if most implementations are going to need to warp
the mouse cursor to do this, the other mouse event coordinates should always
be 0 (or null). Otherwise, implementations on platforms which don't
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
2. During a user-initiated click, you can lock the mouse to the target
or an ancestor without a permissions prompt, but with a persistent
message, either as an overlay or in the browser's chrome.
Does this mean that
On Wed, Jun 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
2. During a user-initiated click, you can lock the mouse to the target
or an ancestor without a permissions prompt, but with a persistent
On Wed, Jun 22, 2011 at 8:27 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jun 22, 2011 at 8:17 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Also, once my mouse is locked, how do I free it?
That was covered in the paragraph you quoted, though cursorily. If
the mouse is locked in this
On 06/22/2011 06:17 PM, Tab Atkins Jr. wrote:
On Wed, Jun 22, 2011 at 8:02 AM, Ryosuke Niwarn...@webkit.org wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr.jackalm...@gmail.com
wrote:
2. During a user-initiated click, you can lock the mouse to the target
or an ancestor without a
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
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
, 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
On Mon, Jun 20, 2011 at 10:18 AM, Adam Barth w...@adambarth.com wrote:
So it sounds like we don't have a security model but we're hoping UA
implementors can dream one up by combining enough heuristics.
A model which I suggested privately, and which I believe others have
suggested publicly, is
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jun 20, 2011 at 10:18 AM, Adam Barth w...@adambarth.com wrote:
So it sounds like we don't have a security model but we're hoping UA
implementors can dream one up by combining enough heuristics.
A model which
On Mon, Jun 20, 2011 at 11:17 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jun 20, 2011 at 10:18 AM, Adam Barth w...@adambarth.com wrote:
So it sounds like we don't have a security model but we're hoping UA
On Thu, Jun 16, 2011 at 6:21 PM, Vincent Scheib sch...@google.com wrote:
- Mousemove event gains .deltaX .deltaY members, always valid, not just
during mouse lock.
Is this implementable?
First-person games typically implement delta mouse movement by hiding
the mouse cursor, warping
On 06/20/2011 10:18 PM, Jonas Sicking wrote:
On Mon, Jun 20, 2011 at 11:17 AM, Adam Barthw...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr.jackalm...@gmail.com wrote:
On Mon, Jun 20, 2011 at 10:18 AM, Adam Barthw...@adambarth.com wrote:
So it sounds like we don't
On Mon, Jun 20, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 20, 2011 at 11:17 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Jun 20, 2011 at 10:18 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 1:06 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 16, 2011 at 6:21 PM, Vincent Scheib sch...@google.com wrote:
- Mousemove event gains .deltaX .deltaY members, always valid, not just
during mouse lock.
Is this implementable?
First-person games typically
On Mon, Jun 20, 2011 at 1:19 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/20/2011 10:18 PM, Jonas Sicking wrote:
On Mon, Jun 20, 2011 at 11:17 AM, Adam Barthw...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr.jackalm...@gmail.com
2. During a user-initiated click,
On Mon, Jun 20, 2011 at 5:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
In a non-mouselock situation, mouse events stop being fired anyway
when the mouse goes outside of the window, so you don't have to worry
about the delta information.
Mouse events continue to be fired while you hold a
On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
On Mon, Jun 20, 2011 at 1:19 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 06/20/2011 10:18 PM, Jonas Sicking wrote:
On Mon, Jun 20, 2011 at 11:17 AM, Adam Barthw...@adambarth.comwrote:
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins
On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
The use-case is non-fullscreen games and similar, where you'd prefer
to lock the mouse as soon as the user clicks into the game. Minecraft
is the first example that pops
On 06/21/2011 01:08 AM, Tab Atkins Jr. wrote:
On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
The use-case is non-fullscreen games and similar, where you'd prefer
to lock the mouse as soon as the user clicks into the
On Mon, Jun 20, 2011 at 3:26 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/21/2011 01:08 AM, Tab Atkins Jr. wrote:
On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
The use-case is non-fullscreen games and similar,
On Mon, Jun 20, 2011 at 1:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
A model which I suggested privately, and which I believe others have
suggested publicly, is this:
1. While fullscreen is enabled, you can lock the mouse to the
fullscreened element without a prompt or persistent
On Mon, Jun 20, 2011 at 3:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jun 20, 2011 at 3:26 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/21/2011 01:08 AM, Tab Atkins Jr. wrote:
On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/21/2011 12:25
On Mon, Jun 20, 2011 at 4:53 PM, Adam Barth w...@adambarth.com wrote:
On Mon, Jun 20, 2011 at 3:30 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Jun 20, 2011 at 3:26 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 06/21/2011 01:08 AM, Tab Atkins Jr. wrote:
On Mon, Jun 20, 2011
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 06/17/2011 01:21 AM, Vincent Scheib wrote:
- 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.
I don't understand
On Sun, Jun 19, 2011 at 5:10 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 06/17/2011 01:21 AM, Vincent Scheib wrote:
- 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
[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
69 matches
Mail list logo
