qt.webChannelTransport is not asynchronous

tl;dr: Calling into C++ from javascript using qt.webChannelTransport freezes all javascript and CSS animation until the C++ code returns, even though the interface suggests asynchronicity by using callbacks, and the docs also say that the communication is asynchronous. Using WebSockets fixes that problem, but feels like overkill and it makes security people uneasy.

Observed Behavior

I attached a sample project. The left button calls into C++ using qt.webChannelTransport/Chromium IPC, the right button using WebSockets. The called method is the same, a processEvent loop that returns after 2 seconds. The left button freezes the progress spinner, the right button does not.

I stepped through the javascript code and to me it looked like the "send" method on the qt.webChannelTransport object does not return until the C++ code finished executing. "send" on a WebSocket returns immediately.

Is this behavior expected? Is there any chance of getting this fixed? If not, it would be great to have this documented: https://doc.qt.io/qt-5/qtwebchannel-javascript.html says "Note that all communication between the HTML client and the QML/C++ server is asynchronous". While the API works with callbacks, in practice that does not help if the WebEngine is frozen.

Workarounds

• One of our products works around this by implementing asynchronicity themselves: The called C++ method returns immediately, is processed in the background, and then C++ signals into JS with the results. They even match the responses to the request manually with unique IDs etc.
• We consider using WebSockets instead so we don't need to rework our API, but we're hesitant as that has a couple security implications.