anthropics / anthropics/claude-code

[Desktop App / Linux] Dragging a pane header does not reposition the pane (menu commands do)

未关闭
#92,044 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
area:desktop area:ui bug has repro platform:linux
主要语言
Python
星标
145k
派生
23.1k
PR 合并指标
PR 指标待抓取

描述

## Summary

On Linux, dragging a pane by its header does nothing — no drag preview, no drop
indicator, no reposition. The documented behaviour
([Arrange your workspace](https://code.claude.com/docs/en/desktop#arrange-your-workspace))
is "Drag a pane by its header to reposition it, or drag a pane edge to resize it."
Edge-resize works. Header-drag does not.

This is **not** the same root cause as #48493 (Windows: header drag moves the whole
window, suspected `-webkit-app-region: drag` conflict). On Linux the window does not
move — the gesture simply has no effect. See "Ruled out" below.

## Environment

- Claude Desktop `1.37937.3`, Linux
- Bundled Electron `42.10.0` (`resources/version`)
- Manjaro Linux, kernel `7.1.9-1-MANJARO`
- Compositor: sway (wlroots), Wayland session, Xwayland available
- Displays: 3840x2160 + 3840x2160 + 3456x2160 built-in, all scale factor 1

**Reproduced independently on a second machine:** Ubuntu, official `.deb` build,
different desktop environment. So this is not specific to sway/wlroots or to the
repackage below.

Note: this is a community repackage of the official Linux build, not the official
`.deb`. The repackage does not patch anything in the pane layout / renderer path;
it adds launcher-level flag handling and profile isolation. Flagging it for
completeness in case it matters.

## Steps to reproduce

1. Open the Code tab with a session.
2. Open a second pane from the **Views** menu (terminal, diff, tasks — any).
3. Drag that pane by its header toward another pane's position.

**Expected:** the pane detaches / a drop target appears / the pane repositions.
**Actual:** nothing happens. No drag preview, no drop indicator, no layout change.

For contrast, the same reposition performed from that pane's triple-dot (`⋮`) menu
works correctly — so the target state is reachable, just not by the documented
gesture.

## What still works

These narrow the fault considerably:

- **Pane edge-drag resize works.** So pointer-move drag handlers in the pane layout
are alive; only the reposition gesture is dead.
- **Title-bar drag moves the window** (default integrated-titlebar mode), so
`-webkit-app-region: drag` is functional and sway honours `xdg_toplevel.move`.
- **HTML5 drag-and-drop works in the app's own Browser pane.** A local probe page
with a `draggable` element and a drop zone fires `dragstart` → `dragenter` →
`dragover` → `drop` → `dragend` normally; a pointer-event reorder list also works.
(Caveat: the Browser pane is a separate `webContents` from the session panes.)
- **The per-pane triple-dot (`⋮`) menu reorders panes correctly.** Every pane
except the leftmost has move commands in that menu, and they work — the panes
reposition as expected. This is the important one: the layout engine's reorder
logic is fully functional, and only the *drag gesture* is dead. That makes this an
input-binding bug (the header's drag handler never engages), not a layout bug.

## Ruled out

| Hypothesis | Test | Result |
|---|---|---|
| Wayland / compositor DnD bug | Ran with `--ozone-platform=wayland` vs `--ozone-platform=x11` (XWayland), two concurrent instances with isolated user-data dirs | Fails identically on both |
| `-webkit-app-region: drag` overlay eating the pointer (the #48493 diagnosis) | Ran with the integrated overlay titlebar vs `frame:true` + `titleBarStyle:"default"` | Fails in both modes |
| Pane header sits inside a window drag region | Drag a pane header on the overlay-titlebar build | Window does **not** move — so the header is receiving the pointer, not the drag region |
| Chromium/Electron HTML5 DnD broken | Probe page in the Browser pane | `drop` fires normally |
| Feature gated off by a flag | Checked all 134 GrowthBook flag ids observed being read from the feature store | No pane-layout / drag flag exists |
| Feature not present in this build | Version is far past the `v1.2581.0` minimum the docs state for pane layout | Present |

Four-cell matrix, all failing:

| | Native Wayland | XWayland |
|---------------------|----------------|----------|
| Overlay titlebar | fails | fails |
| Native titlebar | fails | fails |

## Workaround

Use the move commands in each pane's triple-dot (`⋮`) header menu. They work
correctly.

This is a partial substitute at best: the documented gesture is drag-by-header, the
shortcut table has no move-pane binding (only the `Ctrl+Shift+D` / `Ctrl+Shift+B` /
`` Ctrl+` `` toggles and `Ctrl+\` to close), and the leftmost pane exposes no move
items at all. It is also undiscoverable for anyone following the documentation.

## Note on renderer inspection

I could not inspect the renderer to narrow this further: launching with
`--remote-debugging-port` is refused (`Claude: refusing to start — a debugging or
network-override switch is present on the command line`). Happy to run any
diagnostic that doesn't require that switch.

贡献指南

这个仓库没有索引到贡献指南

调研方向

Start in the Code tab with a session and reproduce the failed drag from a pane header, then compare that gesture's entry point with the working triple-dot move commands. Verify the behavior across the documented Linux setup and confirm that header dragging shows a preview or drop target and repositions the pane without breaking edge resizing or menu moves.

由索引模型根据 Issue 内容生成。

评估

技术栈
electron, linux
领域
desktop
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
活跃
描述清晰度
基本清楚
新手友好度
48/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。