summaryrefslogtreecommitdiff
path: root/static
diff options
context:
space:
mode:
authorStephan Bergmann <stephan.bergmann@allotropia.de>2024-08-14 16:54:49 +0200
committerStephan Bergmann <stephan.bergmann@allotropia.de>2024-08-14 21:57:00 +0200
commitcccc983eb3f0532dbf7e3edf4477ce63ec3d2795 (patch)
treecba9fe3b1bd9277fba60173199ffb43cdaf5a365 /static
parentd193bf5cec65ab55d5a76b3a4f68eb52e5a747f3 (diff)
Emscripten: Run external code on LO's main thread
...and not the browser's main thread. Those are different threads now since 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "Emscripten: Move the Qt event loop off the JS main thread". Running `Module.uno_init.then` on the browser's main thread would never trigger, as that promise is only resolved on LO's main thread. When external code was included in soffice.js via EMSCRIPTEN_EXTRA_SOFFICE_POST_JS, that didn't make a difference: Emscripten effectively replicates that code to all the worker threads, so whatever worker thread resolved the Module.uno_init promise (i.e., the LO main thread) had the external code available and ran it. But when external code was included directly in some HTML file (which "manually" provides a canvas and loads soffice.js, not relying on the qt_soffice.html convenience functionality), it was available in the browser's main thread but not in LO's main thread. For that use case, introduce a new Module.uno_scripts array that can be set up in the HTML file to contain an array of URLs (represented as strings) of scripts to load into LO's main thread. (Alternatively, running external code on the browser's main thread rather than on LO's main thread could be more ideal in the sense that the external code would then have access to the browser's document object. But, for one, it would be less ideal in the sense that we would then potentially again execute LO code (which we call into from the external code via UNO) on the browser's main thread, which would bring back the issues that 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "Emscripten: Move the Qt event loop off the JS main thread" solved. And, for another, when I experimentally tried it out, it caused massive Qt threading issues, so I quickly gave up again.) Change-Id: If01a7859751706f168e93ccac75758ae5ce17cd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171870 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Diffstat (limited to 'static')
-rw-r--r--static/README.wasm.md14
1 files changed, 13 insertions, 1 deletions
diff --git a/static/README.wasm.md b/static/README.wasm.md
index 84635d09390d..c69129303aa5 100644
--- a/static/README.wasm.md
+++ b/static/README.wasm.md
@@ -241,7 +241,19 @@ Module.uno_init.then(function() {
});
```
-
+If you enter the above examples into the browser console, you need to enter them into the console of
+the first soffice.worker.js thread, which is the LO main thread since we use -sPROXY_TO_PTHREAD, not
+into the console of the browser's main thread.
+
+Alternatively, you can do the following: Put an example into some file like `example.js` that you
+put next to the `qt_soffice.html` that you serve to the browser (i.e., in
+`workdir/installation/LibreOffice/emscripten/`). Create another small JS snippet file like
+`include.js` (which is only needed during the build) containing
+```
+Module.uno_scripts = ['./example.js'];
+```
+And rebuild LO configured with an additional
+`EMSCRIPTEN_EXTRA_SOFFICE_POST_JS=/...path-to.../include.js`.
## Tools for problem diagnosis