-
Notifications
You must be signed in to change notification settings - Fork 920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
web: Fix position of touch events to be relative to the canvas #2704
web: Fix position of touch events to be relative to the canvas #2704
Conversation
This is reproducible with this patch: diff --git a/run-wasm/src/main.rs b/run-wasm/src/main.rs
index 6961358d..cd044b3e 100644
--- a/run-wasm/src/main.rs
+++ b/run-wasm/src/main.rs
@@ -1,3 +1,3 @@
fn main() {
- cargo_run_wasm::run_wasm_with_css("body { margin: 0px; }");
+ cargo_run_wasm::run_wasm_with_css("body { margin: 0px; } canvas { position: absolute; top: 100px; left: 100px; }");
} After applying, run it with chrome and in the developer tools switch between device emulation or not. Observe in the console debug output how the mouse event coordinates are relative to the canvas, while the touch coordinates are not. |
I would not add it, and I didn't know what is the problem and how to fix it. |
When using winit with the web on a device that delivers touch events (mobile phone), the coordinates of the touch points that winit delivers to the application should be relative to the winit window. So (0/0) should be the top-left of the window and thus the canvas element. This regressed in the last winit release when dom touch events were changed to be delivered directly. The issue is reproducible with the patch I mentioned on an earlier comment. It places the canvas at a non-zero coordinate and then when tapping within the canvas, the coordinates of the touch point that winit sends to the application are in fact absolute. So tapping at the top-left corner of the canvas now produces (100/100) when it should be (0/0). |
Yes, I've thought that it should be as this pr. But I just did not know and regard this case when I wrote my pr. |
@madsmtm ping. Anything I can do to help move this forward? :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I also checked why calling mouse_position()
wouldn't have been enough, apparently the spec doesn't support offsetX/Y
for touch events.
This will need a rebase, other than that it looks good to me. |
Rebased once more to resolve ChangeLog conflicts. |
ping :-). Anything I can do to help get this merged? |
This should probably wait until after #2662. |
Use the same logic as for mouse events when not captured.
Rebased on top of current master branch. |
Will probably be moot after #2731. Thank you! |
Use the same logic as for mouse events when not captured.
CHANGELOG.md
if knowledge of this change could be valuable to users