HTML inputs are locked after calling `emscripten_set_main_loop`, and still locked after calling `emscripten_cancel_main_loop`

[andrenho]

When calling emscripten_set_main_loop on a SDL aplication, all HTML inputs (like text inputs) have the keyboard interaction locked. I see that I can continue interacting with the page, and with other controls using the mouse, and even keyboard events in the page are caught, but is like the inputs all become readonly.

Although I can't find anything int the documentation regarding this behaviour, this kinda makes sense, as SDL will take over the keyboard. But I would expect that emscripten_cancel_main_loop would return the control to the inputs. However, this is not the case, and the only way to return control to the inputs is by reloading the page.

I tested both in Firefox and Chrome.

Is this expected behvaiour? If so, how can I get the keyboard control back?

[kripken]

We don't currently have a mechanism for this, but we probably should. Many applications just take over the whole page, so the default is usually ok, but there are definitely cases otherwise.

A good starting point is to design an API for this. Tying it to the main loop is an interesting idea, and seems like it could help many use cases, but in general it isn't accurate enough I think. Perhaps we need an explicit API, but I don't have an idea currently for what.

[zengming00]

I face the same issue, Unfortunately, several other similar questions #7043 #4106 #2668 They're all closed. This is a OK solution for me. I just hope that I can temporarily stop receiving events at a specific time and resume receiving events after finishing the work I need

void setEventEnable(int v) {
    int state = v ? SDL_ENABLE : SDL_DISABLE;
    SDL_EventState(SDL_TEXTINPUT, state);
    SDL_EventState(SDL_KEYDOWN, state);
    SDL_EventState(SDL_KEYUP, state);
    SDL_EventState(SDL_MOUSEMOTION, state);
    SDL_EventState(SDL_MOUSEBUTTONDOWN, state);
    SDL_EventState(SDL_MOUSEBUTTONUP, state);
}

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[thenick775]

The solution above has stopped working for me on docker images after emscripten/emsdk:3.1.53

It does stop receiving events, but does not allow html keyboard events to make their way to the html dom elements.

Is there another known workaround?

[kalankaboom]

@thenick775 Thank you very much for giving the version. I recompiled an old project just to realise the DOM inputs had stopped working. I would be quite interested in a solution if possible.

[sbc100]

This this a problem with -sUSE_SDL or -sUSE_SDL=2, or is it a problem even for apps that don't use SDL.

A simple example to reproduce the issue would be very useful.

[thenick775]

Thanks @sbc100 for the attention!

I'll work on getting a minimal repro up here shortly 😎

In my case I'm using SDL2.

[thenick775]

@sbc100 here's what I've got so far in terms of a minimal example using what I'm most familiar with.

With the following sequence of commands I got the following results:

make clean;

With the emcc image version that had the behavior I expected:

make DOCKER_IMAGE_VERSION=3.1.53;

https://github.com/user-attachments/assets/c5324224-6378-41bc-99e7-c55148a2fcc1

Using the latest emcc image version:

make;

https://github.com/user-attachments/assets/c07921c2-466e-49b5-a7bb-b112670d60d5

When I comment out the SDL2 renderer and window initialization the input locking doesn't happen, but also the keyboard input isn't captured (expected). I think this is definitely related to the use of SDL2 in the application I maintain.

[sbc100]

@Daft-Freak does this issue sounds familiar to you? i.e. are there any recent SDL2 changes that might cause this?

[Daft-Freak]

It's not exactly recent, but I think https://github.com/libsdl-org/SDL/commit/92215481146f9225a458e9a09abb85a33b52d9ff caused all key events to get preventDefault-ed, even if the event is disabled. (There's a recent fix for that but I'm not sure it's entirely correct)

[8Observer8]

I have built SDL3 from source a month ago. I have the same problem: https://github.com/emscripten-core/emscripten/issues/22280

Added Solution: https://stackoverflow.com/a/55270572/4159530 Add this line of code before SDL_CreateWindow:

SDL_SetHint(SDL_HINT_EMSCRIPTEN_KEYBOARD_ELEMENT, "#canvas");

[Daft-Freak]

https://github.com/libsdl-org/SDL/commit/6e931bee01b34a9f7a51579bcaf9a95f7f9451ce should fix events when the SDL event is disabled or filtered (same change applied to SDL3).

If you don't want keyboard events disabled entirely, look at SDL_HINT_EMSCRIPTEN_KEYBOARD_ELEMENT (Though the docs are a bit outdated there, I think it just takes a selector now...)

[thenick775]

@Daft-Freak is that commit in an image release anywhere I could test yet?

I definitely like the flexibility of not having to manage focus, while also being able to enable/disable global keyboard events 😎

[Daft-Freak]

Until there's a new SDL release you could try pointing the tag in tools/ports/sdl2.py at the commit or using EMCC_LOCAL_PORTS (?)

Assuming SDL hasn't changed enough to need other updates to the port...

[thenick775]

@Daft-Freak ~~still running some tests, but~~ confirmed, this looks to be fully resolved, at least in emscripten/emsdk:3.1.70 🚀

Edit: tested in the repro above, as well as my mGBA fork that ran into this issue