Change:
} this.contextViewService.hideContextView(false); <ins> // Restore focus here if (this.focusToReturn) { this.focusToReturn.focus(); } </ins> } private onDidActionRun(e: IRunEvent): void {

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.25.1 OS Version: Linux elch10 3.16.0-6-amd64 SMP Debian 3.16.57-2 (2018-07-14) x86_64 GNU/Linux When I set "window.titleBarStyle" to "custom", vscode can not diff files selected from opened editors. Vscode just does not show a split screen with the 2 files being compared. It's like it's ignoring this action. I checked it when "window.titleBarStyle" set on "native", and it works normally. P.S. It also works if I start it from terminal (code --diff) P.P.S. sorry for my english <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Thanks for reporting I see this in Windows as well, when choosing 2 files from the file explorer and selecting the option in the context menu. No errors in the dev tools console
cc for custom menu for diff editor for file explorer
IMHO this should not be a recovery issue, given it is not a regression introduced in July. (i.e. the bug exists in 1.25.x) I cannot reproduce running from sources on . I cannot reproduce running from sources on . I cannot reproduce on built Insiders (based on ) What version of VS Code were you able to reproduce on ? ! Can you reproduce on the Insiders build? ()
You do this in turn, first you select one file, then the other. But I meant if you select 2 files at once. At first I noticed that it does not work only from Open Editors, but now I see that it doesn't work from Repro too. P.S. Yes, I can to reproduce it on Insiders build too.
is still a preview feature. So I think it is fine to push this out to August.
Thank you, I can reproduce now. I believe this affects all the usages of in and possibly more. It looks like that method returns a single selected resource.

I noticed the check for dom focus here The custom context menu will take dom focus from the list. If I remove the requirement, everything works fine, but I don't if that is the right fix. Maybe the context menu service needs to restore focus right before calling the action which is what I do in the menubar. /cc
Moving to August. I think the issue here is that the menu uses the , could that be true?
The issue here is that the new context menu "steals" focus from the open editors and explorer. is written with an assumption that it will only respect what is selected in the open editors view or the explorer if they have focus. Otherwise it could happen that the user selects 3 files in the open editors view, goes to the editor works on something unrelated and triggers a close command from the command pallete -this close command shuold not close the 3 files still selected in the open editors view since it does not have focus. well you are already restoring focus to the workbench when the menu is closed -could you not restore the focus before the commands get executed? the wrongly assumes that if a list has focus than that list is an open editors view, though this does not seem to be the main problem here.
isn't it too late to put the focus back only before running the commands, e.g. does it have an impact on the list of menu items when it shows up? Ignore my comment about , I think we are not using it for the menu.
I do not fully understand your questions. The focus should be back before the command gets executed, since the command will get the appropriate context based on focus.
yeah I was more worried that we have some commands that have a condition where we assume the list has to have DOM focus to operate and these would obviously not work anymore if the context menu steals focus. But maybe this is not an issue, just bringing it up.
good point, but in practice I do not think we have such commands