Trying to use canvas.requestPointerLock not working

[Robert Goulet]

Greetings!

I tried to implement the missing glfwSetInputMode with the following code:

    setInputMode: function(winid, mode, value) {

      var win = GLFW.WindowFromId(winid);

      if (!win) return;

      switch(mode) {

        case 0x00033001: // GLFW_CURSOR

        {

          switch(value) {

            case 0x00034001: // GLFW_CURSOR_NORMAL

              win.inputModes[mode] = value;

              Module['canvas'].exitPointerLock();

              break;

            case 0x00034002: // GLFW_CURSOR_HIDDEN

              console.log("glfwSetInputMode called with GLFW_CURSOR_HIDDEN value not implemented.");

              break;

            case 0x00034003: // GLFW_CURSOR_DISABLED

              win.inputModes[mode] = value;

              Module['canvas'].requestPointerLock();

              break;

            

            default:

              console.log("glfwSetInputMode called with unknown value parameter value: " + value + ".");

              break;

          }

        }

        break;

        case 0x00033002: // GLFW_STICKY_KEYS

          console.log("glfwSetInputMode called with GLFW_STICKY_KEYS mode not implemented.");

          break;

        case 0x00033003: // GLFW_STICKY_MOUSE_BUTTONS

          console.log("glfwSetInputMode called with GLFW_STICKY_MOUSE_BUTTONS mode not implemented.");

          break;

        default:

          console.log("glfwSetInputMode called with unknown mode parameter value: " + mode + ".");

          break;

      }

    },

But it is not working for me. I did the exact same call as in SDL and Glut implementation. I verified that the flow control does indeed get to execute Module['canvas'].requestPointerLock(); and that both Module['canvas'] and Module['canvas'].requestPointerLock are not null pointers. So it does properly call the function, but the browser is not doing anything at all. Any idea why this is not working?

Thanks!

[Alon Zakai]

Does it work in SDL and glut on your browser? There have been browser bugs in the past.

If it does work in them, then there must be some difference. One possible issue is that there needs to be a user event that triggers the pointer lock. What originates the call to there?

Is there an error in the web console.?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Goulet]

Normally, we would like to hide the mouse pointer when we call glfwSetInputMode(windows, GLFW_CURSOR, GLFW_CURSOR_HIDDEN); in C++, but that doesn't always happen from user event. It could be generated from the game script trying to hide mouse pointer in specific cases.

As you suspected, this needs to be a user event that triggers the pointer lock. Turns out it works if I do this:

canvas.onclick = function() {

    canvas.requestPointerLock();

}

I haven't tried SDL and Glut, but most likely its the same limitation. Does anyone know of a good workaround so that we don't require the user's input to do this?

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Alon Zakai]

I could be wrong, but I think there isn't a workaround for that - it's a browser security measure. Pages going fullscreen or hiding the mouse, by surprise, could be used to trick people.

In the SDL code, I know we have a mechanism to make sure that the proper event gets right to the fullscreen/pointer lock request, instead of waiting in the SDL event queue.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Robert Goulet]

After discussing this with my peers, we've came to the conclusion that it is actually proper behavior to add an event listener to the canvas click, that will trigger the pointer lock, in case the GLFW_CURSOR mode is set to GLFW_CURSOR_DISABLED. Please check out my pull request: https://github.com/kripken/emscripten/pull/3905

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.