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!
We already detected that `slint!` in a comment should not be interpreted
as a slint macro, but that detection failed for `slint::slint!` or if
`slint` was twice in the same line.
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.
Basically same as e88b07997f but in the
set_binding_command function.
(made the code more similar to remove_binding_command, I think the two
function should be merged in the future)
This fix editing binding within the root component when it inherits from
something.
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.
Currently, the reported range is the range of the root element, which
doesn't include the name of the component itself.
While the Name of the component itself is used as the selection range.
Vscode assrts that the selection range is within the range:
```
ERR selectionRange must be contained in fullRange: Error: selectionRange must be contained in fullRange
```
So use the full component range for the range instead
This type is poorly implemented and not documented. Let's remove it for now.
It shall remain available in the git history in the event of a resurrection.
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
This changes how the selection range is picked: Instead of using the
`QualifiedName` of the root element, look at the Component's
`DeclaredIdentifier`.
This fixes component declarations without `inherits` clause and is also
nicer than the old approach: We would use the Component id as a name of
the DocumentSymbol and set the inherited type name as selection range.
This is simpler than the previous version and will be easier to
reuse for line-wise deletion, too.
It does sacrifice indention level based (line-) comment splitting, but I
think that will not be missed...
Any comments up to a blank line _before_ a property will be considered to
belong to that property and any comment _after_ the property that starts
without a line break are part of a property now.
There is some extra magic to work when several properties are in the
same line: Basically all comments then refer to the following property.
Update tests accordingly...
