Drag events intermittently not delivered to webviews (drag source dependent)

I spent about 30 minutes trying to debug drag and drop issues with Posit Assistant, and I'm reasonably certain that it's an upstream issue. Unfortunately I can't reliably reprex it: sometimes the drag UI appears immediately, sometimes after a second or two, and sometimes it never appears, all in the same session. It appear to be less reliable when dragging from the OS X screenshot UI than the desktop.

kimi's summary below.

Environment

• Positron 2026.08.0 build 272
• macOS (Darwin 25.5.0, arm64)

Summary

HTML5 drag-and-drop events (dragenter/dragover/drop) are delivered inconsistently to extension webviews when dragging files from outside the window. Depending on the drag source, events arrive promptly, arrive after a noticeable delay (~1s), or never arrive at all — even though the drop target webview is under the cursor and listening on document.

Steps to reproduce

1. Open an extension webview that listens for dragenter/dragover/drop on document (in our case, the Posit Assistant chat panel).
2. Drag a file from the macOS Desktop into the webview.
3. Repeat with a drag initiated from the macOS screenshot thumbnail/dialog (the floating screenshot preview, which uses file promises).

Observed behavior

Instrumented logging inside the webview (performance.now() timestamps on every drag event):

Dragging from Desktop — events arrive promptly and the drop completes:

dragenter t=9300.0ms (session +0.0ms) types=[Files]
dragenter t=9312.4ms (session +12.4ms) types=[Files]
dragleave t=9312.7ms
drop      t=9761.4ms files=1

Dragging from the macOS screenshot dialog — sometimes an "instant drop" (enter and drop 0.7ms apart, no time for drop-target UI):

dragenter t=152987.7ms types=[Files]
drop      t=152988.4ms files=1

And frequently, no drag events are delivered to the webview at all — repeated drags from the screenshot dialog produce zero console output, no drop-target UI, and the drop silently fails.

Expected behavior

dragenter/dragover should be delivered to the webview as soon as the drag crosses into it, regardless of drag source, and a drag that ends over the webview should always deliver either drop or a terminal dragleave.

Notes

• The same webview code in a standalone browser (same Chromium content, no workbench host) shows instant, reliable drag feedback, so this appears specific to the Electron/Positron host environment.
• The failures correlate with the drag source (Desktop vs. screenshot dialog's file-promise drags), suggesting the OS drag session type affects whether events reach the webview.
• Possibly related upstream: electron/electron#18226 (drag DOM events not fired over webviews), microsoft/vscode#96967 (VS Code's pointer-events workaround for webview drags).

Start by reproducing the drag behavior in an extension webview using the listed Desktop and screenshot-dialog sources, then compare it with the standalone browser behavior. Read the linked Electron and VS Code issues for relevant host-level behavior. Done means dragenter/dragover arrive promptly and a drag ending over the webview reliably produces drop or dragleave.