Dropping views into a single-view merged-header custom view container is hard to hit

Type: Bug / UX issue

Summary

Dragging a view into a custom view container that currently has only one view in the single-view merged-header state is very hard to hit. The drop overlay often does not appear even when hovering over the target container title/top area. Once the same target container already contains two views, the normal pane headers are visible again and dropping another view onto a pane header becomes reliable.

This makes view relocation asymmetric: moving a view out of a multi-view container works, but moving another view back into that newly single-view container is difficult or sometimes practically impossible with the mouse.

Steps to Reproduce

1. Use an extension that contributes a custom Activity Bar view container with at least two Webview views, for example:

{
  "contributes": {
    "viewsContainers": {
      "activitybar": [
        {
          "id": "sampleContainer",
          "title": "Sample Container",
          "icon": "media/icon.svg"
        }
      ]
    },
    "views": {
      "sampleContainer": [
        {
          "id": "sample.template",
          "name": "Template",
          "type": "webview"
        },
        {
          "id": "sample.nodes",
          "name": "Nodes",
          "type": "webview"
        }
      ]
    }
  }
}

2. Open the custom container in the Side Bar.
3. Drag Template out so it becomes a standalone single-view container.
4. Drag Nodes from the original container onto the standalone Template container, including the container title/top area.
5. Watch for the drop overlay and try to drop Nodes into the Template container.

Actual Behavior

The drop overlay is very difficult to trigger, and in some attempts does not appear at all. Dropping on the Webview body center does not work reliably, and even aiming at the container title/top area is unreliable.

In a local Extension Development Host probe, the standalone target was in the expected single-view merged state:

• pane class: pane expanded vertical merged-header
• header class: pane-header expanded hidden

Dragging over the single-view merged-header target did not show .monaco-pane-drop-overlay in the tested positions. By contrast, when the target container already had two views, the visible pane header reliably showed #monaco-pane-drop-overlay and accepted the drop.

Expected Behavior

A single-view merged-header view container should still expose a reliable drop target for incoming views. Users should be able to drag another view onto the standalone view/container and merge it into the same container with feedback comparable to dropping onto a visible pane header in a multi-view container.

This could be fixed either by making the merged container header act as a reliable drop target for incoming views, by expanding the per-pane drop target hit area in the single-view merged state, or by otherwise providing consistent drop feedback for this state.

Notes / Possible Cause

This appears related to the Workbench view container behavior rather than extension content:

• Custom view containers are registered with mergeViewWithContainerWhenSingleView: true:
  https://github.com/microsoft/vscode/blob/main/src/vs/workbench/api/browser/viewsExtensionPoint.ts
• In ViewPaneContainer.updateViewHeaders(), the single view's pane header is hidden when merged:
  https://github.com/microsoft/vscode/blob/main/src/vs/workbench/browser/parts/views/viewPaneContainer.ts
• Per-pane view drop targets are registered on pane.dropTargetElement in ViewPaneContainer.

The tested Webview content did not register dragenter, dragover, drop, dragstart, or dragend handlers and did not call stopPropagation() / stopImmediatePropagation() for drag events. During drag, the Webview iframe had pointer-events: none, so this does not look like the extension Webview content intentionally blocking the drop.

Related but not the same as older view DnD feedback issues such as #93104 / #93839: those address drag/drop feedback more generally, while this report is specifically about incoming drops onto a custom container in the single-view merged-header state.

Environment

• VS Code: observed in a VS Code 1.119.0 Extension Development Host
• OS: Linux
• Reproducibility: observed with a real extension using two WebviewView sidebar sections; also reproduced with a minimal WebviewView probe comparing single-view merged vs two-view containers