vscode support: onview activation event doesn't work for a custom webview view

[jcortell68]

Bug Description:

When a vscode extension contributes a custom view that is a webview, and it declares an activation event for the view being opened (onview:myviewid), the plugin doesn't get activated when opening the view and the view shows no content.

One workaround is to declare * as an activation event but that is obviously not ideal. We don't want the plugin activated if the user isn't going to open the view.

Also, for whatever reason, the plugin is properly activated if the app launches with the view already opened. I.e., if the user restarts/refreshes the app with the view already open, then the plugin is activated and everything works as expected.

Steps to Reproduce:

git clone -b webview_panel_noneditor https://github.com/jcortell68/theiasandbox
cd theiasandbox
yarn
yarn start:electron

1. Bring up the command palette (Ctrl+Shift+p on Windows) and trigger the View: Reset Workbench Layout command.
2. Wait for the app to refresh
3. Open the custom view via View > Open View... > My Webview
4. Notice the view comes up but is empty. It should be saying hello to the world.
5. Notice that the stdout lacks the console.log() that the plugin writes from it's activation event (Congratulations, your extension "myext" is now active...). This proves that the plugin was not activated, despite having this in its package.json

"activationEvents": ["onView:myext_myView"],

6. Refresh the app (Ctrl+r on Windows).
7. Notice the custom view is now showing the expected content.

For further proof that the activation event isn't working, change activationEvents so that the plugin is activated on launch unconditionally:

"activationEvents": ["*"],

Now try to reproduce the problem following the steps above and you'll see the empty view behavior doesn't happen.

Finally, the problem happens whether or not the custom view is in a custom view container. In the example plugin provided, a custom view container is used. But declaring the view to be within the built-in explorer container instead results in the same buggy behavior.

Additional Information

• Operating System: Windows
• Theia Version: 1.43.1

[jcortell68]

@martin-fleck-at reproduced the issue on his machine

[msujew]

Maybe related to #13090.

[jcortell68]

I'd say almost certainly. Thanks.

[msujew]

I've encountered this issue when trying to test #13091. While the effects are very similar to the other issue, they have independent problem sources. My findings during a short debugging session:

• activateByView isn't triggered at all due to this issue.
• Seems like the reason is that when trying to prepare the views inside the contributed view container, the views aren't actually registered yet. When stepping through the code with a debugger, you can see that the views are registered after the preparation step.

[jcortell68]

I've encountered this issue when trying to test #13091. While the effects are very similar to the other issue, they have independent problem sources.

Oh wow. Very surprising indeed. Thanks for attempting to verify my issue while fixing the other one. There's no shortage of work for you Theia folks in 2024 ;-)

[jcortell68]

BTW, on a somewhat separate but related note, does Theia not support VSCode's implicit/automatic activationEvent registration that was introduced in 1.74.0?

[msujew]

@jcortell68 It does support it see #12167. The event generator for onView just wasn't implemented correctly, which has been fixed by #13091.

[jcortell68]

Yep. I get that the onView support was broken. I just honestly didn't know if the 1.74.0 auto feature was in Theia or not. Of course, when I ran into my bug (described in this ticket), I didn't explicitly declare the activationEvent and thought that was what was causing the broken behavior. I was wrong, of course. But I just realized I didn't know if the auto-behavior was in Theia. Glad to know it is! Thanks