wry icon indicating copy to clipboard operation
wry copied to clipboard

Pointer lock broken/unusable (Linux/macOS)

Open fivethousand opened this issue 3 years ago • 14 comments

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

fivethousand avatar Nov 05 '21 09:11 fivethousand

Runtime flag was removed 5 years ago. https://bugs.webkit.org/show_bug.cgi?id=165577

keiya01 avatar Jul 29 '22 14:07 keiya01

BTW I have sent an issue for WebKit team. https://bugs.webkit.org/show_bug.cgi?id=244648

keiya01 avatar Nov 29 '22 13:11 keiya01

[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 :)

jowi-papa avatar Nov 29 '22 14:11 jowi-papa

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).

FabianLars avatar Nov 29 '22 15:11 FabianLars

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 :(

jowi-papa avatar Nov 30 '22 17:11 jowi-papa

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.

FabianLars avatar Dec 01 '22 14:12 FabianLars

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)

BlobTheKat avatar Oct 19 '23 09:10 BlobTheKat

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?

eriksachse avatar Dec 14 '23 12:12 eriksachse

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 :(

BlobTheKat avatar Dec 14 '23 12:12 BlobTheKat

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

peabnuts123 avatar May 01 '24 20:05 peabnuts123

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.

FabianLars avatar May 02 '24 11:05 FabianLars

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

ollpu avatar May 27 '24 15:05 ollpu

@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.

ollpu avatar Jul 01 '24 08:07 ollpu

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.

ollpu avatar Jul 07 '24 10:07 ollpu