| Age | Commit message (Collapse) | Author |
|---|
|
...accidentally left over from 91842724235bca73690d67d8084ec7581512d791
"Explicitly .delete() type and interface objects in uno.js"
Change-Id: I84b1b7b5ee283a1a87f5d3aa894776b1bf23c607
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172731
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
These objects use smart proxies, so Embind adds them to a JS finalizer (in JS
runtimes where FinalizationRegistry is available), so it shouldn't be necessary
to manually .delete() them, but Embind then emits "Embind found a leaked C++
instance..." warnings about them, which clutter the JS console.
While it is probably impractical for client code to manually .delete() all such
instances, we can at least explicitly .delete() those that occur in uno.js
itself.
Change-Id: Ia21ca5f0bdb246cc5ea272599befd9a16bc970a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172661
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ie52917f6f487f5de2d67179f67f2935a1f6c838a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172662
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...in snippets that are included with --pre-js/--post-js
Change-Id: I928aa16b78284314796a0645479dce0dfc7b42cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172383
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
...to be used by external code, to mitigate the issue mentioned in the commit
message of cccc983eb3f0532dbf7e3edf4477ce63ec3d2795 "Emscripten: Run external
code on 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."
On the browser main thread, external JS code can now await a Module.uno_main
Promise that provides one port of a MessageChannel. And on the LO main thread,
external JS code has access to the other port of that MessageChannel as
Module.uno_mainPort. (And the external code is completely free in what
onmessage handlers to set up and what form of postMessage calls to use on those
two MessagePorts.)
Change-Id: Iab6bc7676c744eacb70ddd9f3f80f64e9efd1cf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171907
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
...that is resolved from within C++ Desktop::InitApplicationServiceManager once
UNO is fully initialized, so client code can trigger on
Module.uno_init.then(...)
Change-Id: I2d4c542d9729d09f434502e3f966e9ee474e926c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
As we need to generate data upfront for all the UNOIDL entities anyway, we might
just as well extend that with annotations (keyed to some new
Module.unoTagSymbol) that are useful at runtime. The general idea is to let
such annotations be objects with certain well-known keys, the main one being a
string-valued `kind` representing the UNOIDL kind of the annotated data.
As a first thing, individual UNOIDL enum type enumerators are annotated with a
`type` representing the UNOIDL enum type they belong to. That turns out to be
useful for some experimental approach of mine where I wrap the Embind-based JS
binding in something that makes the result more idiomatic JS.
Change-Id: Iec466bab05ba3d1b56b2398e5c361465af49dc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170398
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...with a new Module.catchUnoException JS function that can be used in a JS
catch block to provide the thrown UNO exception as an Any. (For a non-C++
exception, it rethrows the exception, and for a non-UNO C++ exception it maps it
to css.uno.RuntimeException.)
The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have
been moved to a new StaticLibrary_emscriptencxxabi.
Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I6f6e06ad32ffa87242f5a0f41c176149b754e2ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169187
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
When a JS function implementing a UNO interface method returns any or a sequence
type (like queryInterface, getType, and getImplementationId in uno.js), it
could not create a new instance of that type and return it, as it would have
needed to call .delete() on that instance, but couldn't. In uno.js, getType and
getImplementationId solved that by returning pre-instantiated instances that
were deleted in the final release call. But that did not work for
queryInterface, as pre-instantiating the relevant any instances would have
caused cyclic references that would have caused the final release call never to
occur.
So redesign the C++ the_wrapper classes (used by the Embind allow_subclass
machinery): If a UNO interface method returns any or a sequence type (i.e., a
type on which .delete() must be called), change the JS implemenation's return
type from by-value (which meant that the C++ code received a copy) to
by-reference---which means that now the C++ code can access the original
instance and delete it. But which also means that the JS code must always
return a fresh instance now!
(Ideally, the embindmaker-generated code would use by-pointer rather than
by-reference for that return type, but that caused
> emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:116:19: error: static assertion failed due to requirement '!std::is_pointer<com::sun::star::uno::Any *>::value': Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>
> 116 | static_assert(!std::is_pointer<T*>::value, "Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>");
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
errors with no obvious place where to put such allow_raw_pointer markers, so
lets go with this little hack at least for now.)
Change-Id: I3c37b79b8fbf09c19782c6532bc95d4d63505c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169008
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I31647952090224e3195afc636613d1ae56ecb10e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168995
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
...and confine the _impl map to an internal detail. Client code should have no
need to access that _impl map (renamed here to impl_interfaces), nor the
Module.uno_Type_*.reference functions (nor the Module.uno_Type_*.implement
functions).
Change-Id: Ic9c74f22cedb9b5eeecb42d7c13ee0555e92690d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168732
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I0faf224ea51df733cba2edc5e52b1a71c0e96140
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168731
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...so that the unoObject function can be moved there too (so that other code
outside embindtest.js can reuse it)
Change-Id: Id3edb7cede56321db29ba435f221cb7702a3513c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168700
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
