Firefox does not handle modules in web workers yet, but that is what we
asked vite to build (to work around a compatibility issue after
upgrading to vite 4). So Chrome worked, but Firefox did not.
This PR adds a pretty ugly work around to that problem.
The good news is: Firefox will apparently be able to handle modules in
web workers starting with 111, so let's hope we do not need this for too
long!
The update to vite 4 triggered the vite 3 bug vitejs/vite#9879
for us, where the wasm-pack generated .js is included as iife and
therefore the use of import.meta.url gets transpiled to some shim that
tries to access the document, assuming that the JS is running in the
browser instead of in a worker environment.
Explicitly set the output type for the worker to ES modules, so that no
changes are needed and import.meta.url remains in use. This matches the
worker invocation anyway, as we pass "type": "module" to the Worker
constructor.
The upgrade of vite from 2 to 4 in commit
5951ae6272 also brought an update of
rollup to version three. That one documents that relative externals are
resolved to absolute paths by default, which explains the symptom that
the online editor tried to load /some/absolute/path/wasm_interpreter.js.
Resolving back to resolve paths fixes it.
The code used to sometimes throw a strange exception indicating that the
previewer WASM module was not fully up yet when used.
Fix the LspWaiter to really wait for both LSP WASM web worker and WASM
previewer to report back that they are fully up. Previously it only
waited for the Lsp, which surprisingly often works on my machine.
When removing a property binding, the editor notified the Properties
Widget before the LSP was updated. So the LSP continued to provide the
old data on the Property Widgets request. So the removed property
binding was still shown as set.
Work around this by polling the LSP till it returns a source version we
expect (or something newer). This should be save enough I hope.
This sets up the file reader, which has gone missing in action at some
point.
We used to open the main file of the printer demo. That trriggered
loading of all the helper files, but they all came back empty. So any
LSP request that came in got errors as the code was incomplete.
Afterwards the editor loads the files anyway, telling the LSP about the
loaded file each time, filling in the missing information. So after all
files are open in the editor, the information in the LSP is complete and
all LSP commands return proper information going forward.
Stop the LSP from reporting progress information on file loading. This
caused problems with VSCode: First it triggered popups in the UI and
secondly it caused problems for the LSP that was asked to process
requests while calling back into the client.
Adapt the online editor and the two VSCode plugins to work with the
updated code.
Note: I did leave in the progress reporting code that can be used to
handle progress initiated by the _client_ side. That is just
notifications which will not block the LSP in any way and we might need
to support that at some point.
I did remove the Middleware code from the client side though that acted
on the progress information.
The two tests provide somewhat limited value at this time: The Firefox
tests were green before, but we think that should not have been the case
as firefox does not accept the imports in the webworker when serving
with vite in dev mode -- which we did.
Trying to change the test to use the actual generated site fails for
unknown reason: Cypress claims the page reported by `vite prefix` as up
is returning 404 in CI. It works fine locally:-/
This might make firefox a bit happier as the (now) last import defines
some constants. That used to happen between imports and is after all
other imports now.
Ugly work-around, but maybe it helps?
... that communicate with each other over a channel. This means we can
pass one side into a web worker and still have this work.
Short-term this is mean to enable the LSP running in a web worker take
control of the Preview. Mid-term we might be able to also move the
preview into a web worker, but that needs OffScreenCanvas, which is not
available in Safari-based browsers at this time.
I had the mental model of "updating the preview with the new code" since
that is how the LSP works. That is of course wrong here: The Previewer always
compiles again from scratch.
So always feed the main source file to the preview, not the currently
edited one.
Fixes: #2057
We still get some updates from the editor that we do not really need
anymore, but we also get updtaes from the LSP now.
This fixes e.g. the property value being out of sync right after you
changed it in the property editor.
After checking if the instance field is null, we await the promise that
would guarantee DOM attachment. While we await, the browser processes
other microtasks, and we might end up in render() again. This time the
instance field is also null, but the ensure_attached_to_dom promise is
already resolved, so we would create the first slint component and the
associated window. Later we would return from the first await. At this
point the instance field is already set, so we should re-use the
existing window, but since we're not checking anymore, we'll go ahead
and create a second window on the same canvas element.
Fixes#1926
Do not interact with the language server directly in vscode, but use
vscode.commands.executeCommand(...) instead. The online_editor will of
course need to continue to interact with the language server directy, so
this unshares a bit of code. It is not too much and straight forward
code, so that is not too bad.
* Tools: trigger updates for properties view more often
So far you had to move the cursor to refresh the properties view after
start-up. This is no longer necessary.
