[Bug] `markdownPreviewFocus` is `true` even if the markdown preview isn't focused

[wenfangdu]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: v1.60.0-insider
• OS Version: Windows 10

Steps to Reproduce:

1. Change markdown.showSource's when condition to markdownPreviewFocus.
2. Keep a markdown preview open.
3. Focus integrated terminal.
4. Use the bound shortcut to trigger markdown.showSource.
5. Markdown source code file is opened.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• [FR] Conext key for detecting if an editor is a markdown preview (#131286)

[Suven-p]

Is this a bug on markdown-language-features extension ie missing a listener (I couldn't find anything resembling onBlur in extensions api) such as

vscode/extensions/markdown-language-features/src/features/preview.ts

Lines 520 to 522 in aacd843

	this._register(this._webviewPanel.onDidChangeViewState(e => {
	this._onDidChangeViewState.fire(e);
	}));

or is it a bug on extension api cause this._webviewPanel.onDidChangeViewState is not firing when focus changes to terminal?

[mjbvz]

onDidChangeViewState should be fired both when the view becomes active and when the user clicks away from it

If onDidChangeViewState is not getting fired when focusing on the terminal, then there is a bug in its implementation

[Suven-p]

Here's my progress:

vscode/src/vs/workbench/contrib/webview/browser/webviewElement.ts

Lines 214 to 216 in 2f57482

	this._register(this.on(WebviewMessageChannels.didBlur, () => {
	this.handleFocusChange(false);
	}));

didBlur doesn't fire when switching to terminal immediately after opening a markdown preview. Have no idea why. Maybe due to this?

vscode/src/vs/workbench/contrib/webview/browser/webviewElement.ts

Lines 105 to 108 in 2f57482

	if (document.activeElement && document.activeElement !== this.element) {
	// looks like https://github.com/microsoft/vscode/issues/132641
	// where the focus is actually not in the `<iframe>`
	return false;

didBlur event does fire if user clicks on editor area after switching to preview and then switches to terminal. However, this._editorService.activeEditor still points to webview and the issue persists. This is probably easy to solve by checking if webview is focused as in above pr.

vscode/src/vs/workbench/contrib/webviewPanel/browser/webviewWorkbenchService.ts

Line 202 in 2f57482

const activeInput = this._editorService.activeEditor;

[Suven-p]

Tracking active element with setInterval(() => console.log(document.activeElement), 1000) and repeating series of actions: readme.md -> debug window -> search panel -> markdown preview
active element seems to switch between body(of main window not iframe) and iframe. AFAIK there's no pattern to which happens when. Using code-insiders; can replicate with no extensions installed
VS Code version: Code - Insiders 1.62.0-insider (bcb9df5, 2021-10-22T05:16:00.040Z)
OS version: Linux x64 5.11.0-38-generic
Restricted Mode: No

[juliombb]

is this PR appropriate to fix the bug? It does work, but I do not know if it provides the best solution.

[mjbvz]

Yes, please submit a PR

[juliombb]

#139050 is this way ok? Or should I submit it differently?