Module.canvas.exitPointerLock is not a function [ONLY if compiling with SIDE_MODULE=2]

[folays]

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.29-git
clang version 16.0.0 (https://github.com/llvm/llvm-project.git 947d529e4194e0567cfbbea99127066f76c87269)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /usr/local/Cellar/emscripten/3.1.29/libexec/llvm/bin

Failing full example below :

It basically git clone ImGui, and compiles the necessary files unmodified, to launch the "Demo Window".

#!/bin/bash
set -ex

[ -d imgui/ ] || git clone --branch v1.89.2 https://github.com/ocornut/imgui.git

files_imgui="imgui/imgui.cpp imgui/imgui_draw.cpp imgui/imgui_demo.cpp imgui/imgui_widgets.cpp imgui/imgui_tables.cpp"
files_backends="imgui/backends/imgui_impl_sdl.cpp imgui/backends/imgui_impl_opengl3.cpp"
file_main="imgui/examples/example_emscripten_opengl3/main.cpp"

read -d '' -a flags_all <<EOF || true
  -s EXPORT_ALL=1 -fno-exceptions
  -I ./imgui/ -DIMGUI_IMPL_API=extern\ "C"
  -DIMGUI_DISABLE_FILE_FUNCTIONS -DIMGUI_DISABLE_OBSOLETE_FUNCTIONS=1
  -s USE_SDL=2
  -s USE_WEBGL2=1
EOF
read -r -d '' -a flags_debug <<EOF || true
  -s ASSERTIONS=1
  -DDEBUG -D_DEBUG -g
  -s ERROR_ON_UNDEFINED_SYMBOLS=1
EOF

#emcc --clear-cache

em++ -o imgui.wasm    -s SIDE_MODULE=1 $files_imgui    "${flags_all[@]}" -O2
em++ -o backends.wasm -s SIDE_MODULE=1 $files_backends "${flags_all[@]}" -O2 -I ./imgui/backends/

em++ -o web1.html -s MAIN_MODULE=2 imgui.wasm backends.wasm $file_main "${flags_all[@]}" "${flags_debug[@]}" -I ./imgui/backends/

python3 -m http.server 8002

The Problem :

It works well with MAIN_MODULE=1 ; But it wont work with MAIN_MODULE=2, Google Chrome outputs :

Uncaught TypeError: Module.canvas.exitPointerLock is not a function
    at _SDL_ShowCursor (web1.js:6422:28)
    at stubs.<computed> (web1.js:1985:33)
    at 500b98b2:0x17ac
    at _ImGui_ImplSDL2_NewFrame (web1.js:2311:45)
    at main_loop(void*) (web1.wasm:0x6d32)
    [...]

What's weird about it it that there is not much changes needed to make it works ;
There is 3 particular curious behaviours that I observed ;

1) SDL_ShowCursor is the only thing preventing the WHOLE ImGui to works :

--- a/backends/imgui_impl_sdl.cpp
+++ b/backends/imgui_impl_sdl.cpp
@@ -481,7 +481,7 @@ static void ImGui_ImplSDL2_UpdateMouseCursor()
     {
         // Show OS mouse cursor
         SDL_SetCursor(bd->MouseCursors[imgui_cursor] ? bd->MouseCursors[imgui_cursor] : bd->MouseCursors[ImGuiMouseCursor_Arrow]);
-        SDL_ShowCursor(SDL_TRUE);
+//        SDL_ShowCursor(SDL_TRUE);
     }
 }
 

Commenting the above line make it works. (or changing it to SDL_FALSE);

2) Moving the SAME "code execution" of ONLY SDL_ShowCursor to the "main module" also works ;

I mean : this is the "call path" :

main.cpp (main module) calls ImGui_ImplSDL2_NewFrame()
`- which calls ImGui_ImplSDL2_UpdateMouseCursor() at its tail (discards the UpdateGamepads below to simplify)
 `- which calls SDL_ShowCursor(SDL_TRUE) at its tail

If you just do 2 things :

• comment out the SDL_ShowCursor(SDL_TRUE) inside the "side module" (backends/imgui_impl_sdl.cpp)
• add SDL_ShowCursor(SDL_TRUE) inside the "main module" just after the call to ImGui_ImplSDL2_NewFrame()

you would agree that the "code path execution" is the same.
(we just moved a call to SDL_ShowCursor , from the tail of the side module, to the tail of the function calling the side module)

Weirdly, it makes it works.

This is my biggest concern, of course as I shown it is work-around-able, but I wonder WHY moving a call from the "side module" to the "main module" makes it works.

Please note that I tried to enforce the SDL_ShowCursor function to not be "stripped / excluded" from the binary, by adding IN ALL CASES a call to it from the "main module", just before calling the "side module"'s ImGui_ImplSDL2_NewFrame() ;

I also tried to add a new function to the "side module", which just call SDL_ShowCursor, which I used to figure out the effect of calling SDL_ShowCursor from the "main module" vs/ with a slight indirection going through the "side module".

The observations holds : the call to SDL_ShowCursor(SDL_TRUE) from the "main module" passes okay, but if we call a one-liner function from the "side module" doing only this call, it does not work anymore.

So that's my observation : all things equal, calling SDL_ShowCursor(SDL_TRUE) from the "main module" works okay, and calling it (instead, or again, does not matter) from the "side module" JUST AFTER does not work.

So that's a little like "doing this thing from the main module works, doing the same thing from the side module does not work".

3) Slight difference in behaviour between MAIN_MODULE=1 and =2 ;

Possibly observable only on my macOS platform, due to high DPI stuff.

I told you that for MAIN_MODULE=1 to =2, to make it work, I just weirdly had to either :

• comment out the call to SDL_ShowCursor()
• or move this call to the "main module".

Well, I lied. I mean, it made ImGui mostly works, except that a bug of resolution / high dpi appears.
(the mouse coordinates are not where ImGui think it really is). This fix it :

--- a/examples/example_emscripten_opengl3/main.cpp
+++ b/examples/example_emscripten_opengl3/main.cpp
@@ -48,7 +48,7 @@ int main(int, char**)
     SDL_GL_SetAttribute(SDL_GL_STENCIL_SIZE, 8);
     SDL_DisplayMode current;
     SDL_GetCurrentDisplayMode(0, &current);
-    SDL_WindowFlags window_flags = (SDL_WindowFlags)(SDL_WINDOW_OPENGL | SDL_WINDOW_RESIZABLE | SDL_WINDOW_ALLOW_HIGHDPI);
+    SDL_WindowFlags window_flags = (SDL_WindowFlags)(SDL_WINDOW_OPENGL | SDL_WINDOW_RESIZABLE /*| SDL_WINDOW_ALLOW_HIGHDPI*/);
     g_Window = SDL_CreateWindow("Dear ImGui Emscripten example", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 1280, 720, window_flags);
     g_GLContext = SDL_GL_CreateContext(g_Window);
     if (!g_GLContext)

Of course it fixes it, I just commented some things related to HIGHDPI (without even knowing what I did)

What's weird me out there, is that there is some behaviour differences between MAIN_MODULE=1 and `=2.

Baring any linking or symbol problem, I would then have expected all behaviour to be the same ?

It tickles some curiosity, and maybe be a symptom of a bug.

Kind Regards,

[folays]

For what it's worth, #8470 maybe had a similar problem.

[sbc100]

Can you try opening devtools to see what Module.canvas is? Can you attach the backtrace to the failing call to exitPointerLock?

[sbc100]

I looks like perhaps you could be mixing SDL1 and SDL2. In SDL2 SDL_ShowCursor should be a native C++ function. In SDL1 SDL_ShowCursor is JS function:

emscripten/src/library_sdl.js

Line 1817 in 73ab1c5

SDL_ShowCursor: function(toggle) {

Somehow it loos like the SDLv1 version of the function is getting linked in which is odd because it looks like are linking with -sUSE_SDL=2

[Rishab49]

by building with -sMAIN_MODULE=2 (instead of 1). In that mode, the main module is built normally, with no special behavior for keeping code alive. It is then your responsibility to make sure that code that side modules need is kept alive. You can do this either by adding to EXPORTED_FUNCTIONS or tagging the symbol EMSCRIPTEN_KEEPALIVE in the source code.

Refer to this section maybe it can help:
https://emscripten.org/docs/compiling/Dynamic-Linking.html?highlight=sside_module#code-size

[folays]

Can you try opening devtools to see what Module.canvas is?
That's the expected :

<canvas class="emscripten" id="canvas" oncontextmenu="event.preventDefault()" tabindex="-1" width="1280" height="720" style="cursor: default;"></canvas>

Can you attach the backtrace to the failing call to exitPointerLock?
Below is two callstacks.

As you can see, calling SDL_ShowCursor() from either place does not get to the same place.

• from the SIDE_MODULE goes into some web1.js
• from the MAIN_MODULE goes into some web1.wasm

FWIW PLEASE NOTE that :

• The MAIN_MODULE calls it via call $SDL_ShowCursor from web1.wasm
• The SIDE_MODULE calls it via call $env.SDL_ShowCursor from 500b98b2:0x17ac inside (func $ImGui_ImplSDL2_NewFrame (;96;) (export "ImGui_ImplSDL2_NewFrame")

SO there is a difference there of prefixing $env. but I dunno the implems details of Emcripten so...

1) Call stack upon encountering the bug : SDL_ShowCursor(SDL_TRUE) is called by a SIDE_MODULE :

_SDL_ShowCursor (web1.js:6422)
stubs.<computed> (web1.js:1985)
$ImGui_ImplSDL2_NewFrame (500b98b2:0x17ac)
_ImGui_ImplSDL2_NewFrame (web1.js:2311)
$main_loop(void*) (web1.wasm:0x6d3f)
browserIterationFunc (web1.js:11531)
callUserCallback (web1.js:4733)
runIter (web1.js:4789)
Browser_mainLoop_runner (web1.js:4680)
requestAnimationFrame (async)
requestAnimationFrame (web1.js:5142)
Browser_mainLoop_scheduler_rAF (web1.js:4559)
setMainLoop (web1.js:4700)
_emscripten_set_main_loop_arg (web1.js:11532)
$main (web1.wasm:0x6b65)
callMain (web1.js:13847)
doRun (web1.js:13915)
(anonymous) (web1.js:13926)
setTimeout (async)
run (web1.js:13922)
runCaller (web1.js:13820)
removeRunDependency (web1.js:979)
(anonymous) (web1.js:2235)
Promise.then (async)
preloadDylibs (web1.js:2232)
run (web1.js:13884)
runCaller (web1.js:13820)
removeRunDependency (web1.js:979)
receiveInstance (web1.js:1145)
receiveInstantiationResult (web1.js:1161)
Promise.then (async)
(anonymous) (web1.js:1202)
Promise.then (async)
instantiateAsync (web1.js:1194)
createWasm (web1.js:1231)
(anonymous) (web1.js:13256)

which the above yields into this JS code :

  function _SDL_ShowCursor(toggle) {
      switch (toggle) {
        case 0: // SDL_DISABLE
          if (Browser.isFullscreen) { // only try to lock the pointer when in full screen mode
            Module['canvas'].requestPointerLock();
            return 0;
          }
          // else return SDL_ENABLE to indicate the failure
          return 1;
        case 1: // SDL_ENABLE
          Module['canvas'].exitPointerLock(); <<<<<<<<< BREAKPOINT
          return 1;
        case -1: // SDL_QUERY
          return !Browser.pointerLock;
        default:
          out( "SDL_ShowCursor called with unknown toggle parameter value: " + toggle + "." );
          break;
      }
    }

Had I not breakpoint'ed above, it would trigger web1.js:6422 Uncaught TypeError: Module.canvas.exitPointerLock is not a function

2) Call stack upon NOT encountering the bug : SDL_ShowCursor(SDL_TRUE) is called by the MAIN_MODULE :

$SDL_ShowCursor (web1.wasm:0x156d2)
$main_loop(void*) (web1.wasm:0x6d3b)
browserIterationFunc (web1.js:11531)
callUserCallback (web1.js:4733)
runIter (web1.js:4789)
Browser_mainLoop_runner (web1.js:4680)
requestAnimationFrame (async)
requestAnimationFrame (web1.js:5142)
Browser_mainLoop_scheduler_rAF (web1.js:4559)
setMainLoop (web1.js:4700)
_emscripten_set_main_loop_arg (web1.js:11532)
$main (web1.wasm:0x6b65)
callMain (web1.js:13847)
doRun (web1.js:13915)
(anonymous) (web1.js:13926)
setTimeout (async)
run (web1.js:13922)
runCaller (web1.js:13820)
removeRunDependency (web1.js:979)
(anonymous) (web1.js:2235)
Promise.then (async)
preloadDylibs (web1.js:2232)
run (web1.js:13884)
runCaller (web1.js:13820)
removeRunDependency (web1.js:979)
receiveInstance (web1.js:1145)
receiveInstantiationResult (web1.js:1161)
Promise.then (async)
(anonymous) (web1.js:1202)
Promise.then (async)
instantiateAsync (web1.js:1194)
createWasm (web1.js:1231)
(anonymous) (web1.js:13256)

[folays]

I looks like perhaps you could be mixing SDL1 and SDL2. In SDL2 SDL_ShowCursor should be a native C++ function. In SDL1 SDL_ShowCursor is JS function:

emscripten/src/library_sdl.js

Line 1817 in 73ab1c5

SDL_ShowCursor: function(toggle) {

Somehow it loos like the SDLv1 version of the function is getting linked in which is odd because it looks like are linking with -sUSE_SDL=2

That looks like some differentiation bug on the callsite of SDL_ShowCursor(SDL_TRUE) between then main/side module , yes.

As I shown above, when called form the MAIN_MODULE, it just directly calls call $SDL_ShowCursor which goes directly into some :

  (func $SDL_ShowCursor (;300;) (param $var0 i32) (result i32)
    (local $var1 i32)
    (local $var2 i32)
    (local $var3 i32)
    global.get $__memory_base
    i32.const 69984
    i32.add
    i32.load offset=172
[...]

Which smells like a sort-of WASM direct re-implem of the called function.

Whereas calling it from the SIDE_MODULE goes into some call call $env.SDL_ShowCursor which yield into some :

_SDL_ShowCursor (web1.js:6422)
stubs.<computed> (web1.js:1985)
$ImGui_ImplSDL2_NewFrame (500b98b2:0x17ac)
_ImGui_ImplSDL2_NewFrame (web1.js:2311)
$main_loop(void*) (web1.wasm:0x6d3f)
[...]

And this stubs.<computed> above is into some JS code :

        var proxyHandler = {
          'get': function(stubs, prop) {
            // symbols that should be local to this module
            switch (prop) {
              case '__memory_base':
                return memoryBase;
              case '__table_base':
                return tableBase;
            }
            if (prop in asmLibraryArg) {
              // No stub needed, symbol already exists in symbol table
              return asmLibraryArg[prop];
            }
            // Return a stub function that will resolve the symbol
            // when first called.
            if (!(prop in stubs)) {
              var resolved;
              stubs[prop] = function() {
                if (!resolved) resolved = resolveSymbol(prop);
                return resolved.apply(null, arguments); <<<<<<< which calls ....

Which calls into _SDL_ShowCursor (web1.js:6422) containing some :

function _SDL_ShowCursor(toggle) {
      switch (toggle) {
        case 0: // SDL_DISABLE
          if (Browser.isFullscreen) { // only try to lock the pointer when in full screen mode
            Module['canvas'].requestPointerLock();
            return 0;
          }
          // else return SDL_ENABLE to indicate the failure
          return 1;
        case 1: // SDL_ENABLE
          Module['canvas'].exitPointerLock(); <<<<<< HERE is the exception
          return 1;
        case -1: // SDL_QUERY
          return !Browser.pointerLock;
        default:
          out( "SDL_ShowCursor called with unknown toggle parameter value: " + toggle + "." );
          break;
      }
    }
  Module["_SDL_ShowCursor"] = _SDL_ShowCursor;
  _SDL_ShowCursor.sig = 'ii';

[folays]

by building with -sMAIN_MODULE=2 (instead of 1). In that mode, the main module is built normally, with no special behavior for keeping code alive. It is then your responsibility to make sure that code that side modules need is kept alive. You can do this either by adding to EXPORTED_FUNCTIONS or tagging the symbol EMSCRIPTEN_KEEPALIVE in the source code.

Refer to this section maybe it can help: https://emscripten.org/docs/compiling/Dynamic-Linking.html?highlight=sside_module#code-size

Unfortunately I think that is irrelevant.
I'm not building with Runtime Dynamic Linking but with Load-time Dynamic Linking instead.
(I'm not trying to use some dlopen() / dlsym() features)

Specifically, I do that, as per-the-doc :

In order to have the side modules loaded at startup you need to tell the main module about their existence. You can do this by specifying them on the command line when you link the main module. e.g.
[...]
If you are doing load time dynamic linking then any symbols needed by the side modules specified on the command line will be kept alive automatically. For this reason we strongly recommend using MAIN_MODULE=2 when doing load time dynamic linking.

That's what I'm doing. I do "load-time" dynamic linking.

And since at the last linking step (to generate the "main" web1.wasm / .js /. html I list all the .wasm side modules, even If I'm doing MAIN_MODULE=2 (to reduce code size), since I listed all side modules, emscripten / the linker / whatever is supposed to figure out all symbols needed in the main module.

Building with MAIN_MODULE=1 or using EXPORTED_FUNCTIONS shout not be needed here, and would have been needed only if I did not listed all the .wasm side modules at the final linking step.

Regards,

[folays]

I looks like perhaps you could be mixing SDL1 and SDL2.
In SDL2 SDL_ShowCursor should be a native C++ function. In SDL1 SDL_ShowCursor is JS function:

Please also note that I correctly used -sUSE_SDL=2 on ALL modules (main & sides).

It indeed looks like such an error, but made by Emscripten, not me ?

You have my ~ 10-lines shell script in OP to re-fetch and re-trigger the bug.

[folays]

After having read #18443 (comment)
I tried to force all #include of Imgui SDL's to be the "versioned" SDL2 version with #include <SDL2/xxx.h>

The bug still occured.

I also tried to brew install emscripten --HEAD which updated me from 3.1.29 -> HEAD-44b2c2a (3.1.32-git).
(mainly to include possible fixes from #18443)

I also tried em++ --clear-cache.

The bug in OP is still present.

[folays]

As you can see, I used -s ERROR_ON_UNDEFINED_SYMBOLS=1 when building / linking the MAIN_MODULE :

em++ -o web1.html -s MAIN_MODULE=2 \
imgui/examples/example_emscripten_opengl3/main.cpp \
backends.wasm imgui.wasm \
-s EXPORT_ALL=1 \
-fno-exceptions \
-I ./imgui/ '-DIMGUI_IMPL_API=extern "C"' \
-DIMGUI_DISABLE_FILE_FUNCTIONS -DIMGUI_DISABLE_OBSOLETE_FUNCTIONS=1 \
-s USE_SDL=2 -s USE_WEBGL2=1 -s ASSERTIONS=1 \
-DDEBUG -D_DEBUG -g -s ERROR_ON_UNDEFINED_SYMBOLS=1 \
-I ./imgui/backends/ -s NO_EXIT_RUNTIME=1

IF I use instead s ERROR_ON_UNDEFINED_SYMBOLS=0 the bug DISAPPEARS.

With =0 the previously-litigious call $env.SDL_ShowCursor done by the SIDE_MODULE goes directly to :
(which the Chrome debugger "Step into next function call" gives)

  (func $SDL_ShowCursor (;303;) (export "SDL_ShowCursor") (param $var0 i32) (result i32)
    (local $var1 i32)
    (local $var2 i32)
    (local $var3 i32)
    global.get $__memory_base
    i32.const 70032
    i32.add
    i32.load offset=172
    local.set $var1
    block $label0
[....]

With -s ERROR_ON_UNDEFINED_SYMBOLS=0 instead of =1 the majority of the ImGui "Demo" seems to works (mouse & keyboard included) and the size of .wasm files are "reduced" comparatively to a full-all-libs build.

du -sk imgui.wasm backends.wasm web1.wasm web1.js

# size in kB

832     imgui.wasm    # probably normal
16      backends.wasm # really small, expected for a simple "mapping" backend
2772    web1.wasm     # 2,7 MB there, would have been 12 MB+ with MAIN_MODULE=1 or EMCC_FORCE_STDLIBS=1
576     web1.js

The web1.wasm lowers even to 508 kB when also removing the -DDEBUG -D_DEBUG -g.

My best guess would now be that the -s ERROR_ON_UNDEFINED_SYMBOLS=1 has some erroneous behaviour and/or is overzealous in checking wrongs things.

[sbc100]

So in the case when it breaks it seems that we are linking the SDL1 version of SDL_ShowCursor when the main module is linked. I'm looking into how this is possible.

From what I can see it should be impossible get the SDL1 / JS code for SDL_ShowCursor included when -sUSE_SDL=2:

emscripten/src/modules.js

Lines 124 to 137 in 918e131

	if (USE_SDL != 2) {
	libraries.push('library_sdl.js');
	}
	} else {
	if (ASYNCIFY) {
	libraries.push('library_async.js');
	}
	if (USE_SDL == 1) {
	libraries.push('library_sdl.js');
	}
	if (USE_SDL == 2) {
	libraries.push('library_egl.js', 'library_webgl.js', 'library_html5_webgl.js');
	}
	}

Can you share the full set of flags use use when linking your main module in the case when you get the wrong version of SDL_ShowCursor?

[sbc100]

Are you perhaps passing -lSDL in addition to -sUSE_SDL=2?

[sbc100]

(sorry i see you already shared your full link line. I'm trying to repro now)

[sbc100]

I can't repro using simple main and side module using the above settings.

Can you try adding -Wl,--trace-symbol=SDL_ShowCursor to the link line for your main module?