Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't drag Markdown preview to start a new editor group #25854

Closed
gregvanl opened this issue May 3, 2017 · 11 comments · Fixed by #82813

Comments

@gregvanl
Copy link
Contributor

@gregvanl gregvanl commented May 3, 2017

  • VSCode Version: 1.12 Insiders
  • OS Version: Windows 7, 10

Steps to Reproduce:

  1. With a single editor group, open a Markdown file, then Markdown: Open Preview (Ctrl+Shift+V)
  2. Now try to drag the markdown preview to the side to start a new editor group

The drop is blocked.

If you select another file and then try to drag the markdown preview with only the tabbed heading, it works.

@bpasero

This comment has been minimized.

Copy link
Member

@bpasero bpasero commented May 3, 2017

@gregvanl does it work in 1.11?

@mjbvz mjbvz self-assigned this May 3, 2017
@mjbvz mjbvz added the markdown label May 3, 2017
@gregvanl

This comment has been minimized.

Copy link
Contributor Author

@gregvanl gregvanl commented May 3, 2017

@bpasero Yes, this is a regression from 1.11.

@bpasero

This comment has been minimized.

Copy link
Member

@bpasero bpasero commented May 4, 2017

@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?

@dtgriscom

This comment has been minimized.

Copy link

@dtgriscom dtgriscom commented Jan 10, 2018

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.

@HPLegion

This comment has been minimized.

Copy link

@HPLegion HPLegion commented Mar 22, 2018

Problem persists in VSCode 1.21.1 (Win10)

@krupenja

This comment has been minimized.

Copy link

@krupenja krupenja commented Nov 5, 2018

I cannot repro this with VSCode 1.28.2.

@HPLegion

This comment has been minimized.

Copy link

@HPLegion HPLegion commented Nov 7, 2018

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

@gregvanl

This comment has been minimized.

Copy link
Contributor Author

@gregvanl gregvanl commented Nov 7, 2018

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.

@jlyonsmith

This comment has been minimized.

Copy link

@jlyonsmith jlyonsmith commented Mar 22, 2019

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.

@vitaminj

This comment has been minimized.

Copy link

@vitaminj vitaminj commented May 24, 2019

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.

@mjbvz mjbvz added this to the October 2019 milestone Oct 4, 2019
mjbvz added a commit to mjbvz/vscode that referenced this issue Oct 18, 2019
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
mjbvz added a commit to mjbvz/vscode that referenced this issue Oct 19, 2019
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
@mjbvz mjbvz closed this in #82813 Oct 19, 2019
mjbvz added a commit that referenced this issue Oct 19, 2019
* 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
@eamodio

This comment has been minimized.

Copy link
Member

@eamodio eamodio commented Oct 19, 2019

So thrilled about this!

@gregvanl gregvanl added the verified label Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.