[Bug][macOS] 0.2.2-rc.1 frameless window has no drag region — window cannot be moved by mouse (worked in 0.2.1-rc.5)

[kangsai]

Summary

On macOS the DeepSeek Harness desktop window cannot be moved with the mouse after updating to 0.2.2-rc.1. It worked on 0.2.1-rc.5. The window itself is not locked — Accessibility AXPosition can still be written — but there is no draggable region anywhere on the frameless window.

Environment

• App: 0.2.2-rc.1 (CFBundleShortVersionString), build 2026-11-04 17:16
• Channel: nightly (https://download.deepseek.com/dsh-desk/feeds/mac-arm64/)
• Update applied: 2026-11-05 09:57:41 local (see Squirrel/ShipIt log below)
• Previous version (working): 0.2.1-rc.5
• OS: macOS 27.2 (26B123), Mac17,14
• Displays: main 5120×3414 @2x (UI 2560×1707) + secondary 2560×1440
• Window size during test: 1623×1201 (not fullscreen, not minimized)

Update log excerpt (~/Library/Caches/com.deepseek.dsh.ShipIt/ShipIt_stderr.log):

2026-11-05 09:57:39.230 ShipIt Beginning installation
2026-11-05 09:57:41.372 Moved bundle contents from ... to /Applications/DeepSeek Harness.app/
2026-11-05 09:57:42.224 ShipIt Installation completed successfully
2026-11-05 09:57:42.916 ShipIt Successfully launched application

Steps to reproduce

1. Launch the desktop app (0.2.2-rc.1) on macOS.
2. Try to move the window by dragging the top strip: 1px / 4px / 8px / 16px below the top edge (x≈1200–1500), the top-right empty area (x≈2100), or the blank space right of the traffic lights.
3. The window does not move at all. Other apps' windows drag normally.

What I verified (rules out non-app causes)

Check	Result
Is the window locked?	No. AXPosition is settable (AXPosition settable: true); programmatic move from 511,160 → 551,190 succeeded, then restored.
Synthetic drag (CGEvent mouseDown → 10× drag → mouseUp) at 5 different top positions	All no-ops; window origin unchanged.
System load / hang	Not a hang; other windows drag fine; app is responsive.
Accessibility permission	Granted; AX reads/writes work for this app.
Native title bar	None: the window has no AXTitleBar and no AXTitleBar hit target — consistent with titleBarStyle: "hidden" / "hiddenInset".
AX hit-test at y = 163–200	Hits the window's content AXGroup (web content), not a chrome/titlebar element.

Code-level findings (from app.asar)

1. The Electron shell uses titleBarStyle: "hidden" / "hiddenInset", i.e. no native title bar, so dragging must come from CSS -webkit-app-region: drag.
2. ui-web base.css contains the drag mechanism:

   html[data-platform=darwin] [data-window-drag]{-webkit-app-region:drag}
   html[data-platform=darwin] [data-window-drag-recall]{...}

   with a comment describing the intent (translated): "every chrome row marks itself with data-window-drag; ui-web base.css turns that mark into the single darwin drag region".
3. @deepseek-ai/dsh-client-ui-dockkit sets that mark conditionally:

   "data-dockkit-strip": t.id,
   "data-window-drag": e.floats.length === 0 ? !0 : void 0

   i.e. only when floats.length === 0; there is also a MutationObserver-based recall mechanism (data-window-drag-recall).
4. The main UI is rendered inside a <webview>, whose style explicitly sets:

   .k_IHJa_webview{ -webkit-app-region: no-drag; ... }

Hypothesis (not yet verified at DOM level)

On macOS no data-window-drag element ends up outside the <webview>, or the mark is removed by the float/recall logic. Electron does not honor -webkit-app-region inside <webview>/iframes, so the whole window ends up without any draggable area.

Suggested fix

1. Keep a persistent transparent drag layer in the Electron shell, outside the <webview> (≈28–32px tall, spanning the top), with -webkit-app-region: drag; set no-drag individually on traffic-light area, tabs and buttons.
2. Do not let DOM inside the <webview> own window dragging (known Electron limitation).
3. Re-check the floats.length === 0 condition — losing all drag capability merely because a floating panel exists is a high cost; at minimum keep one always-on drag strip.
4. Add a macOS desktop regression test asserting that a visible element with getComputedStyle(el).webkitAppRegion === 'drag' exists in the top-level document.

Workarounds (for other users hitting this)

• Menu bar → Window → Center / Window → Move & Resize (arrow keys) / Fill / Zoom
• Programmatic move via Accessibility (AXPosition) works, e.g. a small helper script.

Additional note (possibly related)

Around the same time, the chat input box briefly stopped accepting typed input (recovered on its own). At that moment a third-party app's renderer was pegged at ~400% CPU on the same machine; unclear whether related — recorded only as a lead.

[wpk865147933]

补充一例同版本实测，观察到与窗口焦点相关：

• DeepSeek Harness Desktop 0.2.2-rc.1，macOS 27.0.1（26A434）。
• 窗口处于激活状态时，在顶部区域按住并拖动，窗口位置不变。
• 先切换到 Finder，使 DeepSeek Harness 失焦；随后从同一顶部区域首次按住并拖动，窗口可以移动。
• 使用 CoreGraphics CGEvent 进行了对照复现：激活时窗口坐标 (448, 234) 不变；失焦后从相同起点拖动，窗口移动至 (492, 284)。其他应用窗口可正常拖动。

静态检查确认界面已有 data-window-drag 和 -webkit-app-region: drag 样式，但尚未验证它们与本故障的因果关系，具体根因待查。

[Forevery1]

@tianyicui

[jiangnanquan]

Another reproduction on a second machine, plus confirmation of the blur workaround.

Environment

• App: 0.2.2-rc.1 (built 2026-11-04 17:16), nightly channel
• OS: macOS 26.6.2 (25G83), Apple M1 Pro
• Window: 1280×820, not fullscreen, not minimized

What I verified

• Programmatic move works: AXPosition is settable and AppleScript moves the window without error — the window itself is not locked.
• Synthetic drag (CGEvent mouseDown → 12× mouseDragged → mouseUp) produced zero movement at four top-strip positions (x≈400 and x≈1200; y = 10 px, 24 px and 40 px below the top edge) and at one content-area control point. Window origin unchanged.
• No drag region anywhere on the window, consistent with the webview-scoped -webkit-app-region hypothesis in the opening post.

Blur workaround is real

A human user on this machine confirmed it manually: click any other app first (e.g. Finder), then press-and-drag the top blank strip once — the window moves. Same observation as @wpk865147933.

Caveat: I could not reproduce that with synthetic events in my environment (my CGEvent drags did not move a Finder window either), so the manual confirmation is the reliable data point, not my synthetic run.

Immediate workaround

osascript -e 'tell application "System Events" to tell process "DeepSeek Harness" to set position of window 1 to {200, 150}'

Still hoping for a fix that keeps at least one always-on drag band in the Electron shell, outside the <webview>.

[jiangnanquan]

Another failure mode found on this machine — worth recording so future reports are not all attributed to the core regression.

Separate trigger: a third-party overlay swallowing the whole drag surface

• App: DSH Desktop 0.2.2-rc.1 and 0.2.2-rc.2 (both rebuilt 2026-11-04 / 2026-11-11)
• OS: macOS 26.6.2 (25G83), Apple M1 Pro
• Plugin: dsh-pet 0.4.5 (third-party desktop-pet overlay)
• Symptom: identical to this report — the window cannot be moved by mouse anywhere on the top strip; programmatic AXPosition still works; focus/blur changes the behaviour.

Disabling dsh-pet immediately restores dragging. Root cause (already diagnosed and fixed upstream in dsh-pet):

/* dsh-pet <= 0.4.6, injected via document.body.appendChild */
#dsh-pet-baifan-root { position: fixed; inset: 0; pointer-events: none; -webkit-app-region: none !important; }

Because the layer is a direct child of <body>, appended after #root, it matches html[data-platform=darwin] body > :not(#root) { -webkit-app-region: no-drag } and its full-viewport box wins the geometry composition. The rc.2 inheritance reset does not change that explicit rule, so upgrading rc.1 -> rc.2 does not help for this trigger.

Verified fixed in dsh-pet 0.4.7 (2026-11-08): the overlay moved to the shell.overlay slot instead of document.body, the app-region declaration was removed, and z-index dropped 1500 -> 50. On 0.4.8 the string app-region appears 0 times in the built lib/client.js.

Suggestion for the core side

The body > :not(#root) rule is correct for portals that must stay clickable, but it also catches full-screen decoration layers (pointer-events: none) that plugins commonly mount on body — pets, effects, watermarks. One plugin with such a layer silently removes every drag row in the window, and the symptom looks exactly like a core regression.

Possible hardening:

1. Make the no-drag exclusion opt-in for body portals (e.g. require data-window-drag-exclude on the portal root) instead of applying it to all non-#root children.
2. Document in the plugin guide that full-screen decorative layers should mount into shell.overlay and must not declare -webkit-app-region.

Upstream references: PC2005-cloud/dsh-pet#324 (root cause) and #323 (verification against 0.4.7).