[w3c/pointerlock] Warp on Exit (#41)

Here's a feature request.

We want to provide two arguments to `exitPointerLock`: a `dx` and `dy` to warp the pointer to a new position just before making the pointer visible.

```
document.exitPointerLock(dx, dy);
```

We're already using the existing pointer lock for a drag-and-drop style application. It is *nearly* a perfect fit.

The one pain point is that as soon as the user drops an object, the cursor reappears back where the object was dragged from, instead of where it’s dropped. This might not sound like much, but in practice it’s pretty disorienting and frustrating.

## Demonstration (of the problem)

https://codepen.io/krarick/pen/EMgRBz


Try to drag the brown box several times in succession.

We’d really like to be able to update the pointer position so that it reappears where the drop happens. That would feel more natural.

This isn’t a general-purpose pointer-warp proposal. This only allows the pointer to be moved once in each pointer-lock session. And it only moves at the very end, when the mouse cursor is transitioning from hidden to shown. This means there will be no visual discontinuity in the pointer’s position on screen — it won’t appear to “jump” from one place to another. The pointer will simply reappear in the new location.

We’d also think maybe the new location should be bounded by the viewport or the pointerLockElement or something. If the new position isn’t in this area, the pointer can perhaps be left where it was, as if exitPointerLock had been called with no arguments.

## Why change the spec? Why not X instead?

Here are some other approaches we tried.

#### Native Drag-n-Drop

In our app we need to process keyboard events while the drag is ongoing, this doesn’t seem possible. Not all keyboard events fire during a drag.

#### Regular Mouse Events (no drag-n-drop, but also no pointer lock)

This approach can miss events — especially mouseup — if the mouse is outside the web browser area. Pointer lock exists to solve exactly this problem.

#### Pointer Lock, but *more*

Instead of engaging pointer lock during a drag operation and exiting it on drop, we might try to stay in pointer-lock for essentially the whole time, and draw our own pointer on the screen. This would be a great deal more work. We’d have to keep track of the pointer’s location, do our own hit detection for click events, and actually show the cursor. And we’d still be left with a UX problem: the standard way to cancel a drag-and-drop operation is the esc key, but esc is reserved to cancel the pointer-lock mode itself. This argues pretty strongly IMO for making the drag operation coincide with pointer-lock mode.

#### [Pointer Clip](https://github.com/w3c/pointerlock/issues/27)?

Maybe! This looks promising, and if it were ready to try, we’d try it.

## Security Considerations / Abuse

Searching the internet, we see that several times before, folks have proposed a general-purpose “pointer warp” API. A common response was that it would be easy to abuse such an API. But in this proposal, we think the potential for abuse has largely already been addressed, since any “warp” operation is covered by all protections (security barriers, prompts, throttling, etc) the browser already applies to pointer lock. There can be at most one warp operation per lock acquisition.

- - -

We looked around the existing issues (both open and closed) and Googled around a bit, and we didn't see anything like this proposed before. Apologies if it has been and we just missed it.

Thanks for reading, and we hope this is helpful!




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/41