wry
wry copied to clipboard
Pointer lock broken/unusable (Linux/macOS)
Describe the bug Pointer lock is broken on both Linux and macOS (and maybe on Windows, too).
Steps To Reproduce
fn main() -> wry::Result<()> {
use wry::{
application::{
event::{Event, StartCause, WindowEvent},
event_loop::{ControlFlow, EventLoop},
window::WindowBuilder,
},
webview::WebViewBuilder,
};
let event_loop = EventLoop::new();
let window = WindowBuilder::new()
.with_title("Pointer Lock Demo")
.build(&event_loop)?;
let _webview = WebViewBuilder::new(window)?
.with_url("https://mdn.github.io/dom-examples/pointer-lock/")?
.build()?;
event_loop.run(move |event, _, control_flow| {
*control_flow = ControlFlow::Wait;
match event {
Event::WindowEvent {
event: WindowEvent::CloseRequested,
..
} => *control_flow = ControlFlow::Exit,
_ => (),
}
});
}
Expected behavior Click on the canvas. The mouse pointer should disappear, and you should be able to move the red dot with your mouse. After pressing ESC, the mouse pointer should be at the same position where it was when entering pointer lock.
Observed behavior Linux: Mouse pointer disappears, but seems to be forced into the top left corner of the window. Getting mouse movement does not work (which is most likely why one wants pointer lock in the first place, otherwise it is rather useless), and when exiting pointer lock (ESC), the mouse pointer is in the top left corner of the window.
macOS: Pointer lock does not work at all.
Note: Pointer lock (of the website used for demonstration) works flawlessly in Safari/Chrome (macOS) and in Firefox/Vivaldi (Linux).
Platform and Versions (please complete the following information): OS: macOS (11.6), Linux (Manjaro 21.1.6) Rustc: 1.56.1
Would you assign yourself to resolve this bug?
- [ ] Yes
- [x] No
Runtime flag was removed 5 years ago. https://bugs.webkit.org/show_bug.cgi?id=165577
BTW I have sent an issue for WebKit team. https://bugs.webkit.org/show_bug.cgi?id=244648
[bug] requestPointerLock() is not work tauri-apps/tauri#5118
is there any time table for the resolution on these issues? just curious. no rush intended :)
not to be pessimistic but we're probably talking about months/years given the past track record 😢 And then there's the problem that webkit is only updated on macOS OS updates (Linux is not much better here).
does this affect windows as well? I was trying to use this lib for gamedev to reduce the foot print but pointerlock is maybe a deal breaker :(
Windows should work, at least i didn't find any contradicting info on that. Either way, we should probably look into refining our cursor grab api a bit similar to rust-windowing/winit#2329 so that we have a valid alternative to the web api (or maybe polyfill it). This probably means that it won't be a thing until the winit merge.
Windows should work, at least i didn't find any contradicting info on that. Either way, we should probably look into refining our cursor grab api a bit similar to rust-windowing/winit#2329 so that we have a valid alternative to the web api (or maybe polyfill it). This probably means that it won't be a thing until the winit merge.
The issue you have mentioned has been merged. I don't have a strong understanding in these rust libraries but now may be a good time to give this issue another attempt? This is quite literally a deal breaker for almost any web-based game that attempts to move to tauri (including mine, that is why I have come here)
Windows should work, at least i didn't find any contradicting info on that. Either way, we should probably look into refining our cursor grab api a bit similar to rust-windowing/winit#2329 so that we have a valid alternative to the web api (or maybe polyfill it). This probably means that it won't be a thing until the winit merge.
The issue you have mentioned has been merged. I don't have a strong understanding in these rust libraries but now may be a good time to give this issue another attempt? This is quite literally a deal breaker for almost any web-based game that attempts to move to tauri (including mine, that is why I have come here)
Just got here, so there is no way to do PointerLock in Tauri? No workaround?
The issue you have mentioned has been merged. I don't have a strong understanding in these rust libraries but now may be a good time to give this issue another attempt? This is quite literally a deal breaker for almost any web-based game that attempts to move to tauri (including mine, that is why I have come here)
Just got here, so there is no way to do PointerLock in Tauri? No workaround?
Not that I found :(
Hey all, what's this issue actually blocked by? It's not clear to me after reading the thread here. I'm willing to contribute if there is a known change that needs to be made. cc @FabianLars
Assuming that waiting for webkit to resolve it upstream (https://github.com/tauri-apps/wry/issues/445#issuecomment-1330618478) is not a solution, then what i was talking about with rust-windowing/winit#2329 simply(?) requires someone to copy (and adapt if necessary) that PR's code into https://github.com/tauri-apps/tao/. After that i'm not sure if there's more required to make it a suitable alternative to the web api as i didn't look too much into it.
Not relevant to the winit/tao implementation, but I stumbled on this too. I noticed that pointer lock works under Wayland, but not X11. (You have to run in Wayland and if you start from a terminal make sure it doesn't use XWayland)
Filed an upstream issue concerning GTK X11: https://bugs.webkit.org/show_bug.cgi?id=273876
@FabianLars
simply(?) requires someone to copy (and adapt if necessary) that PR's code into Tao
That PR/prior work apparently only implements pointer lock for macOS and Linux Wayland. (And the status is still the same in https://github.com/rust-windowing/winit/blob/master/FEATURES.md#input-handling-1). Applications would then need to use different APIs between Windows and macOS, while Linux X11 is still out of luck.
FYI, I merged a fix upstream for Linux X11: https://github.com/WebKit/WebKit/pull/30437
It will be a while before it gets to distributions though.