Pointer lock fails on published version of WebGL game on Chrome, but not Firefox

Hi, I have a WebGL game with a first-person point of view that locks the pointer to ensure the player can smoothly rotate the camera with their mouse. The pointer locks correctly when playtesting in the editor, when building and running locally in any browser, and on Firefox in the published/embedded form on Unity Play. However, in the Unity Play version in Chromium-based browsers, the pointer will disappear, but not lock, when clicking in the game area. This results in improper camera look mechanics (cutting off rotation at a certain angle due to the edge of the screen being reached). This occurs whether in full screen or not. Oddly, there is still a message displayed by the browser indicating that one can exit the pointer lock by pressing Esc.

After reading that browsers may require an event in order to lock the cursor, I changed the cursor lock from occurring automatically to being attached to an invisible UI.Button that covers the entire UI space. So, the current way the pointer lock is implemented is through the method in the following script, which is attached to said button and linked to its OnClick() event handler:

using UnityEngine;
using UnityEngine.EventSystems;

public class CaptureMouse : MonoBehaviour
{
    public void Capture()
    {
        Cursor.lockState = CursorLockMode.Locked;
        Cursor.visible = false;
        Debug.Log("Mouse captured");
    }
}

The same issue occurs whether I use this approach or enable the pointer lock through an if InputAction.wasPressedThisFrame()-type condition in an Update() method on an arbitrary object, so it seems to me that the problem is likely with the locking functionality itself, not the condition through which it is triggered.

Why would this be working in Firefox and on local builds, but not on the Unity Play website on Chromium? Is there some sort of security approach Chromium takes that blocks proper pointer locking? Is there a way to deal with it?

If relevant, I have tried on Chrome 123.0.6312.105 and Vivaldi 7.8.3872.3 (both failing to capture pointer) and Firefox 123.0.1 (captures pointer successfully). All are running on Linux.

Hi!

I know that the Unity Play platform alters the Web template files(i.e. the index.html file) to embed the game build into the pages.
It could be that this change breaks something in the pointer lock implementation.
Can you post a link to the uploaded build on Unity Play that is not working for debugging? If you don’t want to share the whole game you can also share a simple project that just reproduces the pointer lock issue.

I don’t necessarily want to share the whole thing, but here’s a minimal working example that completely reproduces the problem, at least on my computer (if you open on Firefox, you should see expected behavior vs. failure in Chrome): Unity Play | Pointer lock failure simulator game

I might also try uploading the project to itch.io and see if it works any better in their player.

Edit: It works fine on itch.io on Chrome, so it seems like it’s almost definitely a problem with whatever Unity Play is doing to the HTML when it embeds.

Hello Marcel,

We’re having the same issues with our WebGL build (Crazygames, Poki) on Chrome/Chromium after migrating from 6000.2.13 to 6000.3.9. After unlocking the cursor, the browser throws an error if the game tries to lock it again “too fast”.

Indeed there seems to be a minimal time before requesting a lock after an unlock, even if it is actuated by the user re-clicking inside the game’s frame. If this time is not respected, Chrome throws a “SecurityError: The user has exited the lock before this request was completed”.

Note that this does not happen on Safari.

Can you check if they have added unadjustedMovement in this unity version?

It’s been a long time that we are waiting after this (PointerLock unadjustedMovement WebGL), maybe they have added it.

I have the same message when i try the demo here Disable mouse acceleration to provide a better FPS gaming experience  |  Articles  |  web.dev , so it could be related.