`client_x()` should return `f64`

[sebastianv89]

Describe the Bug

MouseEvent.client_x() returns an i32, which should be a f64. The same problem occurs on a few places:

• MouseEvent.client_x()
• MouseEvent.client_y()
• MouseEvent.offset_x()
• MouseEvent.offset_y()
• MouseEvent.page_x()
• MouseEvent.page_y()
• MouseEvent.screen_x()
• MouseEvent.screen_y()

Additional Context

See https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/clientX for additional documentation and https://drafts.csswg.org/cssom-view-1/#idl-index for the current specs.

[Pauan]

This is because we use the Firefox WebIDL (which still uses long).

Since f64 is a superset of i32, and since f64 is the new standard, I agree that we should change it.

[ifiokjr]

How are people getting around this?

I'm currently porting react-aria to wasm and not sure how to work around the lossy values.

[carloskiki]

Is there hope for this feature to land within a year?

[daxpedda]

We don't currently have a roadmap for the next breaking change.

Looking through this I can't really find if this is implemented in any browser right now. Both Chrome and Firefox seem to be still using integers here. Testing this in both browsers on Linux I seem to also be getting integers.

[lpotthast]

I am seeing floating point values in Chrome. Check out https://react-spectrum.adobe.com/react-aria/useMove.html (end of page, dragging the knob should show non-integer values coming from MouseEvent.page_x() and MouseEvent.page_y() respectively).

[daxpedda]

I know nothing about React Spectrum, but checking the newest Chrome source code it still rounds down.

You can easily try it out yourself:

window.addEventListener('pointermove', (e) => console.log(e.pageX, e.pageY))

Would be interesting to know how you were able to produce floating points. I tried the example in the page you linked, which prints integers for me. What device/OS are you using?

To clarify though:

1. We can't fix this in web-sys until the next breaking change regardless of the current browser implementation status.
2. If it doesn't break anything we should probably follow the spec regardless of browser compliance.

[lpotthast]

I'm currently seeing floating point values on: MacOS Sonoma v14.2.1 with Chrome Version 122.0.6261.112 (arm64)

Saw the same behavior on my Linux desktop (OpenSUSE Tumbleweed, up-to-date Chrome as well)

Sure, this would be a breaking change. Would also say that the spec should be followed here.

[daxpedda]

Whats your Window.devicePixelRatio? Maybe the source code I linked is pre-CSS pixel conversion.

[Pauan]

@daxpedda If it doesn't break anything we should probably follow the spec regardless of browser compliance.

Just to clarify, the current spec says that the type is i32, but the draft spec says that the type is f64.

Thankfully f64 is a superset of i32 so we can always safely use f64 regardless of the browser implementation.

[lpotthast]

Whats your Window.devicePixelRatio?

2 on 100% window scaling.

[daxpedda]

Whats your Window.devicePixelRatio?

2 on 100% window scaling.

I confirmed that with a devicePixelRatio != 1 I can easily produce floating point numbers on Chrome as well. Digging into the source code of Chrome I became fairly convinced that this code shouldn't be pre-CSS pixel conversion, so I was a bit confused.

After some more experimentation I found that I could not produce floating point numbers with mousemove (compared to pointermove), so looking at the source code again I found this (which uses this heuristic to make specific PointerEvents still emit integers), which shows that PointerEvent is handled differently to MouseEvent, which is starting to get really weird.

The conclusion here is that there are indeed browsers out there that, at least partly, have already switched to double.