Disable the "Warp mouse" setting, if it is not available.

[MewPurPur]

Control.warp_mouse() is not always available, for example Web doesn't allow it, and Wayland doesn't support it yet AFAIK (I haven't tested this). So on these platforms, the setting should be disabled and maybe some kind of warning should be given.

[ghost]

So, I looked in docs and found that:
"Note: warp_mouse() is only supported on Windows, macOS and Linux. It has no effect on Android, iOS and Web." So, effectively you can move mouse only on Linux X11, MacOS and Windows, everywhere else you can't due to better security

[MewPurPur]

I think the Wayland scenario could be reported as an upstream bug here, other than that, we should follow what the documentation claims.

[ghost]

I think the Wayland scenario could be reported as an upstream bug here, other than that, we should follow what the documentation claims.

It's not a bug, it's feature (TM)
I think easiest and best way to do, is to just make big red label: "THIS FEATURE MIGHT NOT WORK ON YOUR SYSTEM"

[Riteo]

I think the Wayland scenario could be reported as an upstream bug here, other than that, we should follow what the documentation claims.

See #344 (comment)

It's not a bug, it's feature (TM)

That's not the case here IMO. The security argument doesn't hold that well and there's already discussion on improving the situation as linked, it's just that not many people are interested in working on it, from what I can see, as the pointer-constraints-v1 already has partial support for this feature, albeit a bit shortsighted.

If you're curious, this is the problematic statement:

When unlocking, the compositor may warp the cursor position to the set cursor position hint. If it does, it will not result in any relative motion events emitted via wp_relative_pointer.

(Emphasis mine)

This "may", combined with the whole lock/unlock semantics make it a non-ideal API for pointer wrapping, albeit good-enough to not warrant immediate discussion.

[ghost]

That's not the case here IMO. The security argument doesn't hold that well and there's already discussion on improving the situation as linked, it's just that not many people are interested in working on it, from what I can see, as the pointer-constraints-v1 already has partial support for this feature, albeit a bit shortsighted.

Honeslty, I like to think of this as security feature (even if it isn't). I kind of enjoy when programs is not being able to manipulate my cursor whenever they feel like it, particularly games. (For example, Elder Ring has bad habit of blocking cursor inside it's own window, preventing me from moving cursor to second monitor)

[Riteo]

Honeslty, I like to think of this as security feature (even if it isn't).

It kinda is though. The scope of most if not all extensions will always be as small as possible AFAIK. In other words, the current and future pointer manipulation semantics will always be limited to the window or even just its visible surface.