fix: quick input hover initialization

[sdirix]

What it does

Makes sure the global Monaco BaseLayerHoverDelegate is properly initialized with Monaco's HoverService.

This fixes rendering issues caused by uncaught errors when opening a quick input, for example the command palette, before any Monaco editor was initialized. This scenario was easily reproducible in minimal Theia applications, not leveraging all offered Theia extensions.

fixes #15042

How to test

• Adapt the browser example application and remove

  • all AI packages

  • all plugin packages

  • You can use this list for convenience:

    "@theia/console": "1.58.0",
    "@theia/core": "1.58.0",
    "@theia/editor": "1.58.0",
    "@theia/file-search": "1.58.0",
    "@theia/filesystem": "1.58.0",
    "@theia/keymaps": "1.58.0",
    "@theia/markers": "1.58.0",
    "@theia/messages": "1.58.0",
    "@theia/monaco": "1.58.0",
    "@theia/navigator": "1.58.0",
    "@theia/output": "1.58.0",
    "@theia/preview": "1.58.0",
    "@theia/workspace": "1.58.0"
    

• Open the browser example on a workspace you did not use before, so that there are no "recent' entries in your quick input
• Open the command palette Ctrl + Shift + P
• Observe that the palette works as expected

Without the fix, the palette's rendering will be broken and errors thrown in the console

---

As an alternative reproducer you can use the Theia generator, there the problem immediately appears.

Follow-ups

• This fixes the issue for the quick input. Previously I discussed with @tsmaeder to move this code to monaco-init. However as this change is less invasive, I put it into the quick input for now. moved to monaco-init
• This fix should be backported to the community release

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

@sdirix I think I like the solution in monaco-init.ts better, here's why: if another service uses the hover delegate singleton, it might not be fixed with the current fix. You're saying the current solution is less intrusive, but I don't see how that is really the case: we're not really using any monaco services before monaco-init, (the overrides would not work if we do). It's easily testable whether the construction of the hover service works at that time. And we're overriding the singleton as soon as we're opening an editor anyway.
Since this is not relevant for Theia IDE, I would marge this PR after the Theia IDE release. If it needs to be backported for adopters, we should back-port it to the community release anyway, not 1..59

[sdirix]

@sdirix I think I like the solution in monaco-init.ts better, here's why: if another service uses the hover delegate singleton, it might not be fixed with the current fix. You're saying the current solution is less intrusive, but I don't see how that is really the case: we're not really using any monaco services before monaco-init, (the overrides would not work if we do). It's easily testable whether the construction of the hover service works at that time. And we're overriding the singleton as soon as we're opening an editor anyway.

Okay I will try this too

Since this is not relevant for Theia IDE, I would marge this PR after the Theia IDE release. If it needs to be backported for adopters, we should back-port it to the community release anyway, not 1..59

If we don't include it in 1.59 then every user of the yeoman Theia generator will continue to experience the issue (as it will consume 1.59) as well as every adopter using a minimal Theia code base consuming 1.59 (and 1.58 in case we don't backport)

[sdirix]

@tsmaeder updated the fix as discussed