movementX/Y coordinate space #42

EiraGe · 2019-03-21T21:46:31Z

The spec define movementX/Y from screenX/Y. However, while all major browser (except Edge) having screenX/Y in DIP(w3c/uievents#150), movementX/Y implementation are kind of mess here:

movementX/Y	Edge	Chrome	Firefox	Safari
coordinate space	Physical pixel	Physical pixel	CSS pixel	DIP(buggy?)
Scaled by device-scale-factor(OS High DPI setting)	X	X	✓	✓
Scaled by page zoom	X	X	✓	X
Scale by Pinch-zoom	X	X	X	X

It would be nicer and clearer to have better interoperability.
WDYT? @NavidZ @mustaqahmed @smaug----

mustaqahmed · 2019-03-25T16:01:51Z

I agree with Ella re the incompatible implementations.

The current movementX/Y definition in the spec (difference between consecutive screenX/Y values) is problematic from another perspective: screenX/Y spec itself doesn't match the reality! The spec defines screenX/Y as CSS pixels, but most major browsers have DIPs. As a result, browsers have two interpretations of the PointerLock spec: implement movementX/Y either

as DIPs to match most browsers' screenX/Y, or
as CSS pixels to match screenX/Y spec.

Chrome's movementX/Y-in-physical-pixels clearly doesn't look great. We want to change it, see the following possible ways forward:

Modify movementX/Y to DIP to match screenX/Y reality, and keep the PointerLock spec as is.
This has two advantages: (i) seems like a safe change because sites shouldn't be affected by scale change in movementX/Y, and (ii) if we ever change screenX/Y spec to DIP in future, everything will be good from spec perspective.
Modify movementX/Y to CSS pixels to match screenX/Y spec, and keep the PointerLock spec as is.
This essentially pulls the screenX/Y problem (that spec doesn't not matching reality, see linked issue above) into PointerLock without a clear benefit: changing most browsers' screenX/Y to match spec is almost impossible; hopefully one day we will change screenX/Y to match browsers instead, which would then call for a change of movementX/Y to DIPs.
Change PointerLock spec to make movementX/Y in physical pixels.
This completely isolates movementX/Y from screenX/Y coordinate space (and corresponding spec-not-reflecting-reality problem).

Wondering what other browser vendors think about these three options (and possibly other we didn't see).

NavidZ · 2019-03-25T17:37:23Z

Modify movementX/Y to DIP to match screenX/Y reality, and keep the PointerLock spec as is.
This has two advantages: (i) seems like a safe change because sites shouldn't be affected by scale change in movementX/Y, and (ii) if we ever change screenX/Y spec to DIP in future, everything will be good from spec perspective.

So with this first way if we change screenX/Y spec to DIP first we don't need to change Pointerlock spec either. Right? I know that task has hit some road block. So I'm fine with changing the movementx/y to be DIP on its own. Not sure how to specify it very well though. Do we have all the values needed for that specified already?

mustaqahmed · 2019-03-25T19:02:53Z

So I'm fine with changing the movementx/y to be DIP on its own. Not sure how to specify it very well though. Do we have all the values needed for that specified already?

In my first and second points above, I am not proposing any normative spec change at all. I am proposing that browsers would pick one of the two possible interpretations of the current specs (I mean the two interpretations with bullets in my last post). There can be a non-normative note in PointerLock spec though.

tim-janik · 2020-06-08T10:47:52Z

Here is one more suggestion to deal with the situation from an API user perspective.

I'm implementing a slider/knob, that can be adjusted by dragging. For the adjustment during dragging, the distance traveled in clientX/Y coordinates can be used.
But when pointer lock is enganged during dragging, the movementX/Y coordinates have to be used instead. The obvious expectation here would be for movementX/Y to match the clientX/Y coordinate space. This seems to work on FF-77 but not Chrome-83 with devicePixelRatio=2. So the idea is:

Modify movementX/Y to CSS to match clientX/Y (or pageX/Y) coordinate space, this needs a wording correction of the PointerLock spec.
(i) Chrome would have to be fixed to match Firefox' calculations.
(ii) Changing the screenX/Y spec has no effects on movementX/Y.

Alternatively, movementX/Y could be documented/speced to always be scaled up by devicePixelRatio and FF would need fixing. But that doesn't seem to be consistent with any other coordinate pair exposed by the mouse/pointer events. Related crbug#1092358.

Up to at least Chrome/83, the movementX/Y coordinates of a MouseEvent are incorrectly scaled up by devicePixelRatio. Links for the crbug#1092358 and the related W3C discussion: https://bugs.chromium.org/p/chromium/issues/detail?id=1092358 w3c/pointerlock#42 Signed-off-by: Tim Janik <[email protected]>

* knob: EBEAST: b/knob.vue: keep internal drag position to drag with steppings EBEAST: b/knob.vue: allow knob resizing by setting a CSS height EBEAST: b/knob.vue: add UI element for scalar inputs EBEAST: index.html: embedd ebeast/eknob.svg to reference its SVG elements EBEAST: eknob.svg: add knob drawing for <b-knob/> component EBEAST: add CONFIG.dpr_movement to work around crbug#1092358 Up to at least Chrome/83, the movementX/Y coordinates of a MouseEvent are incorrectly scaled up by devicePixelRatio. Links for the crbug#1092358 and the related W3C discussion: https://bugs.chromium.org/p/chromium/issues/detail?id=1092358 w3c/pointerlock#42 EBEAST: utilities.js: add capture_event() helper EBEAST: wrap data-bubble text and add pointy triangle EBEAST: utilities.js: add data_bubble_force() and data_bubble_clear() EBEAST: utilities.js: add restarts and animation frame to debounce() EBEAST: utilities.js: data_bubble_callback(): update bubbles via callback EBEAST: b/hscrollbar.vue: fix hscrolling by using Util.wheel_delta() It was barely possible to trigger horizontal scrolling in Firefox. Now wheel_delta() normalizes the pixel distance so Firefox behviour comes close to Chromium, allthough its steps are less fine grained. EBEAST: utilities.js: add wheel_delta() for normalized scroll deltas EBEAST: b/fed-object.vue: add typedata blurbs as data-bubble EBEAST: b/fed-number.vue: avoid bogus browser generated title tooltip EBEAST: b/fed-object.vue: refactor inline array into named object fields EBEAST: b/color-picker.vue: use data-bubble="" for color info popups EBEAST: utilities.js: hide data-bubble on mouseleave (window looses focus) EBEAST: app.scss: fix data-bubble z-index EBEAST: utilities.js: hide data-bubble on resize and mousedown EBEAST: utilities.js: move ResizeObserver compat decl to the top EBEAST: support free floating tooltips via a data-bubble="" attribute EBEAST: utilities.js: add matches_forof() to search iteratables EBEAST: cssaux.scss: provide dppx() to deal with device pixels EBEAST: index.html: provide a --device-pixel-ratio CSS variable Allow specification of CSS sizes in device pixels. EBEAST: index.html: disable Vuejs `performance` config to fix leaks Firefox (76), Chrome (83) and Electron (7) all show major memory leakage during animation rendering when the Vuejs `performance` config is enabled which uses the performance.measure() web API. The leaks strangely occour *outside* of the JS heap which shows steady usage of a few dozen megabytes while the browser process footprint goes through the roof (gigabytes). Signed-off-by: Tim Janik <[email protected]>

BlobTheKat · 2022-12-01T13:28:24Z

Seriously, how long is this going to take? Are there any work arounds for now?

trusktr · 2024-01-11T02:38:20Z

Can we please get this fixed. movementX, movementY, and movementZ are not reliable at all without consistent units.

For consistency, CSS pixel seem would be the best (a user can multiply by devicePixelRatio to convert to physical if they wish).

This will align with px in CSS which means that mapping movementX, for example, to a difference in width or transform will simply work. f.e.

el.style.width = currentWidth + event.movementX + 'px'

Right now, that will produce weird results where the element being moved or resized will move or resize differently than expected.

The workaround right now is to instead never use movement* properties, and calculate the value directly using some math using the client* properties.

const movementX = event.clientX - previousClientX
const movementY = event.clientY - previousClientY

This has been working better for me, but I haven't tested with user zoom.

It seems like basing it on CSS pixels is the way to make it result in correct calculation based on the web content. I've never wanted the delta to be anything other than aligned with the content (which means CSS pixels).

trusktr · 2024-01-11T08:12:46Z

Here's a demo showing movementX is not usable in Chrome (on a macbook air m2 with dpr 2):

https://codepen.io/trusktr/pen/OJqROvd/823fc7ec003e4652d97ff13e32d91b80

When you drag left/right on the demo, notice the mouse moves different speed than then orange border.

Here's a demo using movementX = event.clientX - previousClientX, and it works as expected, dragging moves the box at the same speed as the mouse:

https://codepen.io/trusktr/pen/gOEwXdZ/6257b761fdc13f2b7c354ed2cf422af4

neonfuz · 2024-01-12T17:47:51Z

Here's a demo showing movementX is not usable in Chrome (on a macbook air m2 with dpr 2):

https://codepen.io/trusktr/pen/OJqROvd/823fc7ec003e4652d97ff13e32d91b80

When you drag left/right on the demo, notice the mouse moves different speed than then orange border.

Here's a demo using movementX = event.clientX - previousClientX, and it works as expected, dragging moves the box at the same speed as the mouse:

https://codepen.io/trusktr/pen/gOEwXdZ/6257b761fdc13f2b7c354ed2cf422af4

I would like to point out this is zoom level dependent. On my monitor the first demo worked fine until I zoomed in.

Cross browser normalization of movementX,movementY and deltaX,deltaY is a hot mess, see: https://bugs.chromium.org/p/chromium/issues/detail?id=1092358 https://bugzilla.mozilla.org/show_bug.cgi?id=1392460 w3c/uievents#181 w3c/pointerlock#42 mdn/content#11811 Signed-off-by: Tim Janik <[email protected]>

…e and Firefox * MOUSE-WHEEL: ui/util.js: remove unused wheel2scrollbars ui/b/pianoroll.js: reinstante hzoom and vzoom adjustments via Ctrl ui/util.js: use Mouse.wheel_delta() ui/b/knob.js: use Mouse.wheel_delta() ui/b/pianoroll.js: properly scroll via deltaY from Mouse.wheel_delta() ui/mouse.js: wheel_delta(): provide .x, .y, .z in pixels ui/b/app.js: defer ZMove handling to mouse.js ui/mouse.js: include ZMove notification handling ui/index.html: start mouse.js early on ui/mouse.js: add event_movement() and wheel_delta() to fix event coords Cross browser normalization of movementX,movementY and deltaX,deltaY is a hot mess, see: https://bugs.chromium.org/p/chromium/issues/detail?id=1092358 https://bugzilla.mozilla.org/show_bug.cgi?id=1392460 w3c/uievents#181 w3c/pointerlock#42 mdn/content#11811 ui/index.html: disable modulepreload, it causes module errors in Firefox-122 Signed-off-by: Tim Janik <[email protected]>

psnet · 2024-05-09T10:16:11Z

This is important topic

BlobTheKat · 2024-05-10T20:56:49Z

Can we bump the priority of this issue

EiraGe mentioned this issue Mar 21, 2019

movementX/Y when zoom in/out #23

Closed

NavidZ mentioned this issue Sep 3, 2019

Specification status report for TPAC 2019 #50

Closed

mustaqahmed mentioned this issue Oct 26, 2021

Status report and planning for TPAC 2021 #75

Closed

taoyouh mentioned this issue Jan 4, 2022

Issue with "MouseEvent.movementX": should add browser compatibility note mdn/content#11707

Closed

taoyouh mentioned this issue Apr 28, 2022

Add warning about browser details of MouseEvent mdn/content#15473

Merged

3 tasks

amrbashir mentioned this issue Aug 27, 2022

[bug] MouseEvent.MovementX and MouseEvent.MovementY do not work correctly on Linux tauri-apps/tauri#5063

Closed

github-actions bot mentioned this issue Nov 7, 2022

MouseEvent インターフェイスの記事を更新 1 (親記事～movementY) mdn/translated-content#9779

Merged

github-actions bot mentioned this issue Nov 18, 2023

MouseEvent 以下の記事を更新 mdn/translated-content#17011

Merged

github-actions bot mentioned this issue Jan 11, 2024

Improve warning regarding movementX and movementY mdn/content#31651

Merged

This was referenced Jul 1, 2024

Web: fix MouseMotion coordinate space rust-windowing/winit#3770

Merged

Browser support tracking rust-windowing/winit#2875

Open

This was referenced Jul 26, 2024

Convert noteblocks for web/api folder (part 8) mdn/content#35132

Merged

ja: Convert noteblocks to GFM Alerts (part 10) mdn/translated-content#22704

Merged

github-actions bot mentioned this issue Sep 27, 2024

[zh-CN]: sync translation for MouseEvent.{movementX, movementY} mdn/translated-content#23799

Merged

mogimogitomato mentioned this issue Dec 28, 2024

Add drag screen koedame/rails-mermaid_erd#105

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

movementX/Y coordinate space #42

movementX/Y coordinate space #42

EiraGe commented Mar 21, 2019

mustaqahmed commented Mar 25, 2019

NavidZ commented Mar 25, 2019

mustaqahmed commented Mar 25, 2019

tim-janik commented Jun 8, 2020

BlobTheKat commented Dec 1, 2022

trusktr commented Jan 11, 2024 •

edited

Loading

trusktr commented Jan 11, 2024

neonfuz commented Jan 12, 2024

psnet commented May 9, 2024

BlobTheKat commented May 10, 2024

movementX/Y coordinate space #42

movementX/Y coordinate space #42

Comments

EiraGe commented Mar 21, 2019

mustaqahmed commented Mar 25, 2019

NavidZ commented Mar 25, 2019

mustaqahmed commented Mar 25, 2019

tim-janik commented Jun 8, 2020

BlobTheKat commented Dec 1, 2022

trusktr commented Jan 11, 2024 • edited Loading

trusktr commented Jan 11, 2024

neonfuz commented Jan 12, 2024

psnet commented May 9, 2024

BlobTheKat commented May 10, 2024

trusktr commented Jan 11, 2024 •

edited

Loading