One big issue is that you do not have a full operating system underneath for you to utilize.
What you get is the same sandbox in which javascript lives. In some aspects, it is somewhat similar to a single-threaded microcontroller where there is just one thread in which to operate, limited filesystem access and limited resources.
One of the unusual and tricky bits about using Qt for WebAssembly, is that the exec loop is not typical. The Emscripten main loop is co-operative, after each event has a turn to run, control is then returned to the browser. Any blocking of the event loop will mean the web page in which your application runs will become unresponsive.
This is all fine and dandy for simple applications that use one main loop, but gets complicated when you try to exec a secondary loop. To stop the execution of an event loop, emscripten throws an exception, which leads to all kinds of fun. It also means it never returns to the same place that you expect it. So any modal dialog that uses exec() will not return values. Less than ideal.
Take for instance QColorDialog. Typical use is as such:
QColorDialog dlg(parent);
dlg.exec();
QColor color = dlg.selectedColor();
Which is basically what QColorDialog::getColor does.... and does not work with Qt WebAssembly, because exec() does not return to the same place as you expect! The call to selectedColor will never get called.
What you can do is use a non-modal dialog with the show() or in the case of QColorDialog open() function and use Qt's signal/slot API to retrieve the selected QColor.
QColorDialog *dlg = new QColorDialog(this);
connect(
dlg, &QColorDialog::colorSelected,
[=](const QColor &selectedColor) {
qDebug() << Q_FUNC_INFO << selectedColor;
});
dlg->open();
https://emscripten.org/docs/api_reference/emscripten.h.html#browser-execution-environment
You can also learn more about Qt for WebAssembly and other things in the book I wrote:
Hands on Mobile and Embedded Development with Qt 5
