WebView elements don't see `change` when navigating away. `focusout` event not sent.

[Colengms]

Does this issue occur when all extensions are disabled?: No, it involves extension APIs.

Version: 1.101.2 (system setup)
Commit: 2901c5a
Date: 2025-06-24T20:27:15.391Z
Electron: 35.5.1
ElectronBuildId: 11727614
Chromium: 134.0.6998.205
Node.js: 22.15.1
V8: 13.4.114.21-electron.0
OS: Windows_NT x64 10.0.26100

We're using a WebView for extension configuration. We have some "change" events plumbed up to intercept settings changes and apply them.

        elements.forEach(el => {
            el.addEventListener("change", this.onChanged.bind(this, el.id));
        });

If the user has the WebView 'document' open with the text focus still within a modified text field, and they click somewhere else or on another app, the change is correctly processed. However, if they navigate to another document (with focus still in modified text field) such that the WebView document becomes immediately not-visible (now behind the other document), the lose of focus is NOT processed and the text modification the user made is lost.

Hooking up a focusout event:

        document.addEventListener('focusout', (event) => {
            console.log(`Focusout event`);
        });

I can see that this is never generated in the repro scenario.

Repro video:

Recording.2025-05-23.170653.mp4

My guess is that because the WebView is becoming no longer visible, there is a higher-level deactivation that is occurring that is not allowing the WebView to properly process loss of focus.

C/C++ Extension repro: microsoft/vscode-cpptools#13636

[mjbvz]

The webview's iframe is destroyed when it is moved to a background tab unless you set retainContextWhenHidden on the webview. This is like closing the tab in a web browser. We then recreate the iframe when the tab becomes visible again

afaik focusout /blur events aren't fired when a document is closed so the current behavior sounds expected to me

I recommend syncing over the text state eagerly to handle this. You can then treat either textbox.blur or WebviewPanel.onDidDispose as committing the current state

[Colengms]

Hi @mjbvz . We don't trigger on blur, we trigger on "change". While focusout is arguable, I think it would be more correct to process any lingering edits (i.e. "change") of any field with active edits that has not yet been applied, before disposing. We should be able to use "change" consistently and not have to monkey with aggressively setting aside edit contents (including which field was edited), to work around this unusual behavior.

[mjbvz]

Does it work that way with a normal webpage in a
browser when you close it?

[Colengms]

We're not closing anything.

[mjbvz]

When the webview tab is hidden (and you don't set retainContextWhenHidden) the iframe content is destroyed. This is the same as the tab closing if the page was shown in a web browser

[Colengms]

Yes, that is apparently the behavior as it's been implemented. But you seem to be implying that it's intuitive, when it certainly is not. You're effectively disposing of the webview as an optimization, conditionally, by default, any time it's navigated away from in such a way that it's obscured (but not when navigated away from in a way in which it does not become obscured). To avoid this unusual behavior requires someone to understand that it's due to this underlying disposal policy. It would seem much more intuitive for this optimization to provide the expected events that would be involved with normal deactivation, rather than having the caller need to implement some hacky work-around.

Enabling retainContextWhenHidden is a fine (albeit not easily discoverable) work-around for us. However, we do NOT require the webview to remain in this scenario. It would be absolutely fine if you disposed of it after delivering the needed deactivation events. An extension shouldn't need to care whether or not the webview was navigated away from in an internally destructive or non-destructive way. A good design would abstract away any need for higher level code to know anything about that.

[mjbvz]

Try something like the input event instead of change. Or sync over the state more eagerly like I already suggested. retainContextWhenHidden won't actually fix the problem because it won't help if the tab is closed or VS Code is closed. We do not ever want to allow extensions to block operations like this

When we build these APIs we try to think of what makes most sense for our users and for the entire VS Code ecosystem. And yes sometimes this will mean a bit more work on your side