Incorrect value return type for input device coordinates

[dnlsndr]

Describe the Bug

The Mouse input event defines four functions:

• client_x()
• screen_x()
• x()
• offset_x()

all of those return i32 values, which is not really correct. Normal systems that work with a mouse or 'primitive' input device may only work on pixel basis, but newer input devices such as pen inputs, digitizers and such return high precision float values which are apparrently casted into i32 by the mentioned functions. And since other input event types such as PointerEvent extend the normal MouseEvent, they also have the same issue. This becomes extremely noticable for applications such as note writers that are maily used on tables with pen inputs.

Steps to Reproduce

1. Clone this repo: https://github.com/onmyflow/wasm_bindgend_event_coordinates_issue
2. npm intall & npm start
3. open the website on a device with a input device like a pen
4. open the developer console
5. click somewhere on the blank page and look at the output
6. notice that the log from JS has decimal numbers while the log from rust has casted the floats into integers

Here a picture for fast reference:

Expected Behavior

All input event device coordinates have to output a f64 value for full precision

Actual Behavior

The before mentioned functions cast input event device coordinates into i32 which is not correct

Additional Context

I'm still not alltoo familiar with the intricacies of wasm-bindgen, so I'm not sure how to fix this issue and create a PR by myself.

[alexcrichton]

Thanks for the report! This is probably an error in the WebIDL definitions which need to be changed to reflect this.

[dnlsndr]

Ok, had a look at it, would be a relatively simple yet severe change. How are breaking changes handled? Will these only be merged for new major versions of wasm-bindgen?

[alexcrichton]

Currently we've just been postponing breaking changes, we don't have a great way of landing them unfortunately other than "we're pretty sure no one's using this since it's clearly wrong", which I'm not sure is the case here.

[dnlsndr]

Yeah, i think this is one of the more common functions. Maybe one could introduce those breaking changes with version 1.0.0?

[alexcrichton]

Indeed!

[QuantumBadger]

It looks like this is still an issue unfortunately. If it's not feasible/desirable to make breaking API changes, perhaps it's worth adding new functions with different names, e.g. offset_x_f64() and offset_y_f64()? It's a bit messy but would preserve backwards compatibility.

I'm currently adding canvas/WebGL support to Speedy2D, and need high-precision offsetX/offsetY values so that the mouse position is accurate if the page is zoomed in or otherwise scaled. For a 640x480 canvas, zooming in by 500% still produces integer mouse coords in the range (0-640),(0-480), meaning that the precision is reduced to 1/5.

I've actually just tested the following Javascript code in Firefox, and still only get integer values, so even if web_sys is updated, browser support may not be present anyway! So if anyone's aware of a higher-precision way to get the coordinates in this case, please let me know!

document.getElementById("my_canvas").addEventListener("mousemove", function(event) {
    console.log(event.offsetX + ", " + event.offsetY);
});

[dnlsndr]

@QuantumBadger what input device are you testing with? I've noticed that only stylus inputs and similar return floading point values, while a mouse pointer alsways only returns an integer.

[QuantumBadger]

Hi @dnlsndr, I was using a mouse, with the page zoomed in so that the physical pixels were smaller than the page's pixels. It's interesting that using a stylus results in floating point values -- it could be a browser bug that the mouse events are "low resolution" when the page is zoomed in, but it's been about six months since I tried this.

[canselcik]

I think this is still ongoing and especially noticeable on handheld devices.

[daxpedda]

Closing as duplicate of #2079.