Can't drag Markdown preview to start a new editor group #25854
Comments
|
@gregvanl does it work in 1.11? |
|
@bpasero Yes, this is a regression from 1.11. |
|
@mjbvz I see that dragging the tab over the markdown preview turns the mouse icon into a "drop not allowed" cursor. This could either be the Electron update, or changes we did to the webview within (e.g. context-isolation). A quick test to disable context isolation though did not help. Were there other changes that could have an impact? E.g. CSP settings? |
mjbvz
added
windows
|
Confirmed in VSC 1.19.1 (1.19.1) on OS X 10.10.5: you can't start a new edit group by dragging a Markdown preview to the right edge of the screen. |
|
Problem persists in VSCode 1.21.1 (Win10) |
|
I cannot repro this with VSCode 1.28.2. |
|
I agree, this seems to have been fixed, even though it feels a bit "laggy" to me compared to dragging code edit tabs. But it works, guess the issue can be closed now |
|
Still doesn't work for me in 1.28.2 if the active editor is the Markdown preview. I think the issue is that the Markdown preview can't be a drop location. |
|
You can repro this issue easily. With a Markdown view open, dragging the tab does not show the new group shadows. Cmd+T to create a new tab, and with it active, drag the Markdown tab over it. The new group shadows show up and you can dock the tab. I'm on 1.32.3 on macOS. |
|
Still a problem in 1.34 - seems to me the obvious thing to do immediately after opening a preview - to drag it to one side, to see it side-by-side, but you're blocked from doing so unless you switch back to the markdown code first. |
Fixes microsoft#25854 This change does the following: - Have the webview editor create an `EditorDropTarget`. This is required because the webview itself is not part of the normal editor dom (it exists as a top level node in the workbench so that we never reparent it). This means that the standard `EditorDropTarget` does not work. - Make webviews set `pointer-events: none` while a drag is happening. When a drag happens on Electron's webviews or a normal iframe, no drag and drop events seem to get generated. The fix is to set `pointer-events: none` while the drag is happening. But it's also difficult to detect when the drag is happening because the `EditorDropTargets` class eats the drop event itself. The only reliable seeming way I could find to determine when a drag starts and ends is looking at global events on the window. This workaround is pretty ugly. I'm not sure if there's some better approach that would work with webviews
* Fix drag and dropping of editors for webviews Fixes #25854 This change does the following: - Have the webview editor create an `EditorDropTarget`. This is required because the webview itself is not part of the normal editor dom (it exists as a top level node in the workbench so that we never reparent it). This means that the standard `EditorDropTarget` does not work. - Make webviews set `pointer-events: none` while a drag is happening. When a drag happens on Electron's webviews or a normal iframe, no drag and drop events seem to get generated. The fix is to set `pointer-events: none` while the drag is happening. But it's also difficult to detect when the drag is happening because the `EditorDropTargets` class eats the drop event itself. The only reliable seeming way I could find to determine when a drag starts and ends is looking at global events on the window. This workaround is pretty ugly. I'm not sure if there's some better approach that would work with webviews * Add public `createDropTargets` helper on editorPart Unfortunatly we can't add this method to IEditorGroupsService as it uses the `HTMLElement` type * Rename function to createEditorDropTarget * Use instanceof instead of cast
|
So thrilled about this! |
and others
Steps to Reproduce:
The drop is blocked.
If you select another file and then try to drag the markdown preview with only the tabbed heading, it works.
The text was updated successfully, but these errors were encountered: