Hydrogen Desktop

Type: Bug report

Symptom: Dragging file(s) from another (native Windows) window and dropping them into HD's VS Code Explorer fails. Two errors observed:

1. A modal JS error dialog: Cannot read properties of null (reading 'name')
2. A VS Code toast: The file(s) to paste have been deleted or moved since you copied them. Error: ENOENT: no such file or directory, stat '/home/adom/project/adom-desktop-widget-manager'

Environment: HD v0.1.95 (build ec8551c), workspace runtime = WSL2 / code-server (VS Code served in a WebView2 browser surface), AD 1.9.100.

Root cause — host ↔ container filesystem boundary

The Explorer is code-server (VS Code in a browser webview) whose filesystem is the WSL2 container (/home/adom/...). The file being dragged lives on the Windows host. A native OS drag-drop from another window lands on the WebView2 surface, but the browser can't hand code-server a usable host-file reference or the file bytes:

• Error 1 (reading 'name'): VS Code's drop handler expects a File/entry object from the DataTransfer, but a cross-window native OS drag into the sandboxed webview yields no readable File object → it dereferences null.name. This is an unhandled path in the webview drop handler.
• Error 2 (ENOENT on a container path): VS Code falls back to treating the drop as a paste/move and resolves the item against the container filesystem — stat('/home/adom/project/adom-desktop-widget-manager'). The Windows source has no counterpart there (or the path is resolved before it exists), so it ENOENTs. The path in the error is a Linux/container path, confirming the drop was resolved inside the container, not against the real Windows source.

Net: native drag-drop cannot cross the host→container boundary, and code-server's fallback produces these two errors instead of a clean "unsupported" message.

Why HD is the right place to fix it

HD owns the Tauri/WebView2 window shell that wraps code-server. Per HD's startup handler registration (new-window, navigation, context-menu, script-dialog, permission, target=_blank), there is no native file-drop handler — so OS file drops fall straight through to the webview and fail. HD is the only layer that can see the real Windows source paths of a drop (via the WebView2 / Tauri file-drop event) and it already has a host→container file-transfer bridge (adom-desktop send_files / HD file transfer) to deliver them.

Suggested fix

1. Intercept native file-drop at the HD shell (WebView2 Drop / Tauri file-drop event) so OS drops never reach code-server's failing handler.
2. On drop, take the real Windows paths, copy them into the workspace via the file-transfer bridge (into the current Explorer folder / workspace root, or a drop-target the user picks), then reveal the new files in the Explorer (adom-vscode reveal).
3. Handle folder drops too (the dropped item here was the adom-desktop-widget-manager folder) — recurse via the bridge.
4. Add a visual drop affordance (highlight + "Copy N file(s) into workspace?") so the behavior is discoverable, and a clear toast on completion/failure instead of the raw reading 'name' / ENOENT errors.
5. Until the intercept lands, at minimum swallow the null-deref and show a friendly "drag-drop from the host isn't supported yet — use "Send to workspace" / the file bridge" message.

Repro

1. In HD (WSL2/code-server workspace), open the Explorer.
2. From a native Windows window (Explorer/desktop/another app), drag a file or folder onto the HD Explorer pane and drop.
3. Observe the Cannot read properties of null (reading 'name') dialog and the ENOENT paste toast.

Two error screenshots available. Host log pull was unavailable this session — the adom-desktop CLI symlink in the container is currently dangling (points at a removed dist/linux build), so the bridge was unreachable; noted separately to the user.