Hello! First, can you please explain your use case and why the current implemention doesn't work for you?

The usage of Promises in the view space is troublesome for me for messaging, because I run wasm without ASYNCIFY in my view and I decided to go back to a simpler "stupider" callback based approach which solved the issues I had.

If I understand correctly, there's a way for you to solve the issue without modifying the library, but you want to invoke a bound function (send a message to the C++ side) directly from WASM, and awaiting the promise is problematic? I'm not very familiar with WASM so I might need some more help with understanding the problem.

I'm not yet entirely convinced that the webview library should allow users to hijack the internal message handler. I don't think we'll want to make any guarantees that promises won't be used elsewhere in a way that can reintroduce the problem for you in some way, and I doubt we can provide customization points whenever that happens.

An idea that could potentially make sense anyway is to allow registering custom message handlers. That way I imagine you could send and handle arbitrary messages. Even so, I'm not convinced that we would want to guarantee a promise-free use case here.

Can you think of a better way to solve the problem?

Thanks.

I cannot call an async function from WASM (and the ASYNCIFY overhead is NOT acceptable): I just realised that this is not true anymore:
https://emscripten.org/docs/api_reference/val.h.html#_CPPv4NK10emscripten10emscripten3valcv8co_awaitEv
emscripten-core/emscripten#20413
But I am not sure if I can go up to that enscripten version, because of Ubuntu20 and clang 14 support reasons, I will have to check that.

I could have also possibly just replaced the view js part and kept the message handler the same I think, but I decided against it, so that I dont have to adhere to the format from webview and so I can just parse the json once in my detour function.

Basically what I need(ed?) is that the browser communication is 2 layered: a stupid way that just wraps the browser APIs which I can use to implement my boilerplate message dispatching myself and then the convenience layer provided by webview itself (that does message dispatching).

EDIT: which only concernes the receiving side because sending into the view is possible. Receiving arbitrarily is not. Thats why i called this issue as is.