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
On Monday, November 9, 2015 at 12:10:05 PM UTC-5, Alon Zakai wrote: > > 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. > > On Fri, Nov 6, 2015 at 9:04 AM, Robert Goulet <[email protected] > <javascript:>> wrote: > >> 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! >> >> >> On Friday, November 6, 2015 at 11:53:53 AM UTC-5, Alon Zakai wrote: >>> >>> 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.? >>> >>> On Fri, Nov 6, 2015 at 8:14 AM, Robert Goulet <[email protected]> >>> wrote: >>> >>>> 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! >>>> >>>> -- >>>> 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 [email protected]. >>>> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
