Change:
import { Extensions as EditorInputExtensions, IEditorInputFactoryRegistry } from 'vs/workbench/common/editor'; import { WebviewEditorInputFactory } from 'vs/workbench/parts/webview/electron-browser/webviewEditorInputFactory'; import { KEYBINDING_CONTEXT_WEBVIEWEDITOR_FOCUS, KEYBINDING_CONTEXT_WEBVIEW_FIND_WIDGET_VISIBLE } from './baseWebviewEditor'; <del> import { HideWebViewEditorFindCommand, OpenWebviewDeveloperToolsAction, ReloadWebviewAction, ShowWebViewEditorFindWidgetCommand } from './webviewCommands'; </del> <ins> import { HideWebViewEditorFindCommand, OpenWebviewDeveloperToolsAction, ReloadWebviewAction, ShowWebViewEditorFindWidgetCommand, SelectAllWebviewEditorCommand } from './webviewCommands'; </ins> import { WebviewEditor } from './webviewEditor'; import { WebviewEditorInput } from './webviewEditorInput'; import { IWebviewEditorService, WebviewEditorService } from './webviewEditorService';

Discussion:
VSCode Version: 1.3.0-insider OS Version: windows7 Steps to Reproduce: Download My extension: Run command to open my webview. Problem: Drag Button into TextArea. Dragfeedback overlay will prevent my dragging action. Typing some text in the textarea. Use to select all, Nothing happen. Reason , the default drag handler is prevented. , handler is prevented. !
Taking out the preventDefault() from the dragover allows to drop any file/url into the window to open it and replace all of VS Code, so I am not easy to make a change there...
for the second issue.
Problem is that is not guarded by and which is done
As I am working on a Windows machine, I can definitely remove that. IIRC there was something inherently broken on the Mac ( not working in dev tools or something weird like that) that made and I do that change and not have a for .
Moreover, regardless of our changing the rule for , I think the problem on the mac is that: appears in the menu the menu natively captures the keydown the menu sends to the wrong renderer process the command invocation But maybe things have changed since we last looked at this.
My workaround to make it happen in dev tools is in
I have pushed the fix you suggested, but I don't have a mac to try it out. Please try to do Ctrl+A in a native input such as the find widget or the git commit input box and check if it still works. If it does not work, then please revert
I can confirm that Cmd+A selects all in input fields and still in the editor. It does not select all in the <webviewthough. There is another bug where Undo/Redo do no work in native input fields and I guess that is related. Can we apply your fix for these commands too?
I see an issue when selecting an item in the explorer and pressing it selects all of the editor tho it doesn't have focus. Is that the intent? !
That is what I'm trying to explain here unsuccessfully. It is not the keybindings service that executes , but on the mac is captured by the menu (because it appears as an accelerator in the menus) and then the menu sends a ipc message to the focused renderer process and executes .
In fact, that is the case with all accelerators that appear in the menu on the mac.

This is not the case under windows.
The select all code falls back as a last chance to select last active editor:
It also does the manual select all on input fields:
The select all behaviour in the explorer has been like that before already because we do not have multi select in the explorer. The fact that focus does not move has been reported already as far as I remember and is not very nice.
yeah - we should either focus the editor after selecting all or ignore the command if the editor isn't focused
I would just focus the editor, many people actually find it useful that Ctrl+A always goes to the editor, so I would not disable that.
! I like it. what do you think? seems as easy as adding before
:+1: Please do the change, we wrote that code together at your machine a long time ago :)
Pushed via
It is not clear to me if my change fixed this issue.
Did the changes resolve your issue?
is ok now. But Problem1(drag in webview) is still unresolved.
Thanks for the feedback. Assigning to for the dnd part
I tried your suggested change from and it causes an issue as you can see from the GIF below. Please feel free to provide another PR with a solution, I am not sure though it is that easy. Your change is preventing all DND operations from happening in the webview and this means you cannot drop a tab or file anymore onto the editor area to open it. Worse, it opens the actual file as source into the webview. !
We maybe can add some code in ?
I would appreciate a PR in this area that solves it because this is not really on the radar for August (given other priorities) and I think it is "nice to have" and stretches the ability what you can do with webviews (which I find questionable).
Also, I find it bad UX if it blocks a user from dropping a tab into the editor area because to a user it might totally not obvious that something inside the webview accepts the drop and we will get many bugs for that.
yeah, this issue is contradictory. it impossible to meet all requirements simultaneously.

The Ctrl+A issue is back on the table and if you find a solution via PR that does not break the world, we would be happy to review :)
can we also have the function to use mouse right click in webview, and I also want native support ctrl+F to find
yes, but please follow our issue guidelines and create separate issues for separate issues.
I already include this request in my original issue, however you closed it...
trying to teach you how to write good issues :)
, sorry for the inconvenience, I thought the title and the description is easy to read, while in fact it's poor. Anyway, is this feature request in your recent schedule?
currently not, but if someone is willing to help, we accept pull requests.
thanks
any progress about this?
Reopening this to track just the drag and drop part. Select all was by
It would be fantastic to enable drag and drop into webviews. This screenshot shows how my extension's toolbox palette is able to render in the sidebar thanks to . However, that doesn't do much good unless the user can drag items from the palette onto the canvas webview displayed in the editor. Is this enhancement so foundational a change that it's unlikely to be considered? !
I have a similar problem as Donald is having above. This looks like a fundamental problem with this framework. Are there any design patterns or workaround to drag and drop functionality in webview? What was the rationale to not support this kind of feature?
The original example seems to work for me in iframe based webviews (which are now the default in the latest VS Code insiders) ! The original linked extension no longer works since was removed so I pasted this in the webview sample extension instead: If you are still seeing issues with drag/drop in webviews, please open a new issue with an example extension so we can investigate