The drag and drop function is no longer functional in the latest code

[wszgrcy]

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

work success

Version: 1.90.2
Commit: Unknown
Date: Unknown
Electron: 29.4.0
ElectronBuildId: undefined
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Linux x64 6.5.0-41-generic

work failed

Version: 1.91.0
Commit: Unknown
Date: Unknown
Electron: 29.4.0
ElectronBuildId: undefined
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Linux x64 6.5.0-41-generic

This issue occurs when opening a webview type window while developing extensions
Steps to Reproduce:

1. I use mdn demo https://mdn.github.io/dom-examples/drag-and-drop/copy-move-DataTransfer.html
2. add html to webview html
3. open webview .dragover loss,and can't drop

I use tag 1.90.2 compile and run vscode-oss work .but use latest commit aea213b7fcc7de5c24ad797ac1af209b159d451f doesn't work.

[gjsjohnmurray]

Does the technique described at #213045 (comment) get you to the exact commit where the problem appeared?

[wszgrcy]

Does the technique described at #213045 (comment) get you to the exact commit where the problem appeared?

51917e8
After constantly switching commit. I found that after submitting '51917e869e4d643f9ecd5cfc6b618ba264d905c1', there was an abnormal drag in the webview
And according to the submitted information, it was found that when dragging inside the 'webview', it is necessary to hold down the 'shift' to drop it inside the 'webview'. Is this a normal operating behavior
Cannot hold down 'shift' before dragging, it is necessary to hold down while dragging, which is a strange operation behavior

[swordensen]

And according to the submitted information, it was found that when dragging inside the 'webview', it is necessary to hold down the 'shift' to drop it inside the 'webview'. Is this a normal operating behavior

I believe it is expected operating behavior

@mjbvz said this on the original issue #182449

Here's the behavior we want:

If the user drags a file over a webview without holding shift, they see the editor drop overlay. Dropping the file opens in that editor group
Once the user presses shift while dragging, they instead start dropping the content into the webview. The drop overlay should now go away
Once the user releases shift, the drop overlay shows again

Also the tooltip indicates that the user should hold shift to drop a file when using the editor view. Maybe we should include a similar tooltip when dropping into webviews?

[edit] I realize now that this issue was due to ALL webview drag events being captured by my drag event listener and pushed up to VSCode. We only want to handle drag events that have a file attached.

and I want to apologize to @wszgrcy for not understanding the issue originally.

[ZoolMons]

And according to the submitted information, it was found that when dragging inside the 'webview', it is necessary to hold down the 'shift' to drop it inside the 'webview'. Is this a normal operating behavior

I believe it is expected operating behavior

@mjbvz said this on the original issue #182449

Here's the behavior we want:

If the user drags a file over a webview without holding shift, they see the editor drop overlay. Dropping the file opens in that editor group
Once the user presses shift while dragging, they instead start dropping the content into the webview. The drop overlay should now go away
Once the user releases shift, the drop overlay shows again

Also the tooltip indicates that the user should hold shift to drop a file when using the editor view. Maybe we should include a similar tooltip when dropping into webviews?

Hello swordensen,

I also meet this situation when I want to drag files on to webView, and I saw you already fixed and merged in #209211. But I didn't find related information in the change log from v1.90.1 and v1.90.2. Do you have a plan to release the pull request?

[wszgrcy]

And according to the submitted information, it was found that when dragging inside the 'webview', it is necessary to hold down the 'shift' to drop it inside the 'webview'. Is this a normal operating behavior

I believe it is expected operating behavior

@mjbvz said this on the original issue #182449

Here's the behavior we want:

If the user drags a file over a webview without holding shift, they see the editor drop overlay. Dropping the file opens in that editor group
Once the user presses shift while dragging, they instead start dropping the content into the webview. The drop overlay should now go away
Once the user releases shift, the drop overlay shows again

Also the tooltip indicates that the user should hold shift to drop a file when using the editor view. Maybe we should include a similar tooltip when dropping into webviews?

not editor=>webview or webview => editor;
Internal drag in webview will fail
That is to say, the drag drop function on the same HTML page requires the use of 'shift' to drag
And it's not about holding down shift first, but dragging and then pressing shift to take effect
Isn't it very against common sense?

[mjbvz]

Holding shift to drop is expected when dropping external content into a webview, such as from the explorer. However it's unexpected here as there's no file content on the drag event that could be opened in an editor. That's why you don't see even any overlay that mentions holding shift

I'm going to revert #209211 for now until we can get a more reliable fix for the original issue

[swordensen]

I see I didnt understand the issue. I didn't run into it myself because I was only dealing with dragging and dropping files.

Maybe we should only bubble up the drag event if the user is dragging a file.

[edit] I added a video of the problem and I think I know how to fix it.

Recording.2024-07-03.094541.1.mp4

[swordensen]

Okay, so I updated my new PR so that only drag events coming from outside the editor with a file will be consumed by the new drag event listener.

Now internal drag events will not be blocked.

AND if you happen to drag and drop a file it will not open on its own.

Recording.2024-07-03.104047.mp4

[rzhao271]

I'm unable to view the full mp4s or download them on MS Edge on Windows. I wonder if they got corrupted.
The MDN demo seems to work on my end, now.
Verified.

[ssibrahimpur]

Kindly make an immediate release with the solution as this is blocking our production release for a plugin which uses drag drop feature.

[Yoyokrazy]

The issue has been closed and verified, so this issue should be fixed in the incoming Stable Recovery release, coming this week.

[ssibrahimpur]

[like] Sachin Shivagonda Ibrahimpur reacted to your message:

…

________________________________ From: Michael Lively ***@***.***> Sent: Tuesday, July 9, 2024 8:25:22 PM To: microsoft/vscode ***@***.***> Cc: Sachin Shivagonda Ibrahimpur ***@***.***>; Comment ***@***.***> Subject: Re: [microsoft/vscode] `The drag and drop` function is no longer functional in the latest code (Issue #219047) The issue has been closed and verified, so this issue should be fixed in the incoming Stable Recovery release, coming this week. — Reply to this email directly, view it on GitHub<#219047 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALKQNNMZY7TZKG7FEERQFYTZLRBLFAVCNFSM6AAAAABKA5EKI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJYGY3DOMZTGI>. You are receiving this because you commented.Message ID: ***@***.***>

------------------------------------------------------------------------------ Disclaimer: The following terms shall apply to the recipients of the mails received from Celestial Systems. The content of this email is intended for the person or entity to which it is addressed only. This email may contain confidential information. If you are not the person to whom this message is addressed, be aware that any use, reproduction, or distribution of this message is strictly prohibited. If you received this in error, please contact the sender and immediately delete this email and any attachments ----------------------------------------------------------------------------------------

[daulis]

@mjbvz This problem was reintroduced in vscode 1.92.0

The way that I can reproduce is to do an interactive rebase (GUI) via GitLens

[swordensen]

I thought this might happen. If the maintainers want to merge the recovery branch into main (so the previous fix sticks) I do not mind handling conflicts on my fix PR #219148

[stefanfrings2]

I also noticed that the problem was re-introduced in version 1.92.0 using ThunderClient. It worked fine in vscode 1.91.0.
Related issue in ThunderClient: #1567

Please re-open this issue.

[swordensen]

I also noticed that the problem was re-introduced in version 1.92.0 using ThunderClient. It worked fine in vscode 1.91.0. Related issue in ThunderClient: #1567

Please re-open this issue.

afaik the bug was introduced in 1.91.0 resolved in 1.91.1 and re-introduced in 1.92.0 . A fix has been merged into main but, it has not been released.

However, if you can re-create the issue by building from source with the latest changes please let me know and I will look into it.

In the meantime, we have to wait for the next release/patch before the fix is available.

[ccastrotrejo]

Hi all, Logic Apps vscode extension is also having trouble with the drag and drop experience no working inside our own webview. I tested in version 1.92.0. This really hits our main experience in the extension, therefore users can't use it correctly. Could you please make a hotfix for the 1.92.x version? . Azure/LogicAppsUX#5265

[ccastrotrejo]

This is now fixed in vscode 1.92.1. Thank you so much!

[swordensen]

Awesome! If anyone encounters any other issues with Drag and Drop (with extensions) please open a new issue and tag me. I can probably fix it pretty quick as I am fairly familiar with the nuances at this point.