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
On Mon, Aug 29, 2011 at 2:29 AM, Vincent Scheib sch...@google.com wrote:
I believe first developers seek a specifiable solution that will provide a
consistent application experience on all platforms and API implementations.
Yes, the raw input method provides this. (I don't like calling it
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
-- Provide mouse deltas without hiding the cursor, alternatively provide a
bounding rectangle for mouse --
(See Klaas's recent suggestions)
It may be possible, but significant implementation hurdles remain for
this.
First, we must be able to specify the units that mouse deltas will be
On Mon, Aug 22, 2011 at 8:13 PM, Vincent Scheib sch...@google.com wrote:
What are the units of .movementX/Y if we're reading 'raw' input device
coordinates? Are they consistent across devices and platforms? Can we
specify them?
I don't think any units can be specified here, since it's
-- 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
I agree with you that the deltas should be in a separate event. That would
also be the most logical because moving the cursor(corresponding to a
mousemove event) and physically moving your mouse are separate things. If
mousemove wasn't already used for cursor movement(mousemove imo should
have
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
On Thu, Aug 11, 2011 at 7:27 PM, Vincent Scheib sch...@google.com wrote:
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
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 this to
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.
As for mouse locking isn't that a completely distinct feature
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
On Fri, Aug 12, 2011 at 2:27 PM, Vincent Scheib sch...@google.com wrote:
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
A few comments:
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
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
I recently saw what appeared to be the AG group complaining that the
html WG didn't care to specify Accessibility bits even though W3
policy requires considering both internationalization and
accessibility.
I know that we like to innovate and let everyone else backfill the
missing pieces later,
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
On Fri, Jun 24, 2011 at 12:00 PM, Vincent Scheib sch...@google.com wrote:
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
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
On Thu, Jun 23, 2011 at 10:10 PM, Charles Pritchard ch...@jumis.com wrote:
There are certainly cases where extreme coordinates could be useful to an
application.
Those corner cases will have to be thought about, by those implementing
such apps.
Moving the cursor to the top of the screen
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
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
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.
Adam
On Mon, Jun 20, 2011 at 9:07 AM, Vincent Scheib sch...@google.com wrote:
A range of security methods have been discussed. Please read the thread in
detail if
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 the
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 the
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
61 matches
Mail list logo
