Skip to content

fix(window): grant the capability the header drag has always needed - #59

Open
RichardHightower wants to merge 2 commits into
mainfrom
fix/window-drag-capability
Open

fix(window): grant the capability the header drag has always needed#59
RichardHightower wants to merge 2 commits into
mainfrom
fix/window-drag-capability

Conversation

@RichardHightower

Copy link
Copy Markdown
Contributor

Summary

01M1QN6CE0P31CYJZFG7K9D3K7

Versions 0.6.2, 0.6.3, and 0.6.4 each shipped a frontend drag fix that could not work. The frontend was right. The Rust capability file was the block.

Tauri 2 gates startDragging() behind core:window:allow-start-dragging. The capability file granted only core:default, which expands to core:window:default, and that set is 26 read-only queries plus allow-internal-toggle-maximize. Neither allow-start-dragging nor allow-toggle-maximize is in it.

Every drag call was rejected by the access control list, from Tauri's own injected drag.js and from our handler alike. Nothing was logged, because windowDrag.ts swallowed the rejection in an empty catch. That is why each attempt passed review and failed on a Mac.

The OS used to draw a title bar that dragged for free. It went away in 8fe4093 when titleBarStyle became Overlay, and no code replaced what the OS had done.

Changes

  • Grant core:window:allow-start-dragging and core:window:allow-toggle-maximize.
  • Replace both empty catches with a one-time console.warn naming the capability file. The path is Tauri-only, so the end-to-end console gate is unaffected.
  • Unit-test both grants.

Test plan

  • bun run typecheck
  • bun run guard:client (58 modules)
  • bun test src (276 pass)
  • The new guard fails when the grant is removed, and passes when restored
  • Mac dogfood: the window drags from the header. This is the check the previous three releases skipped, and it now passes on a real .app.

🤖 Generated with Claude Code

https://claude.ai/code/session_0124JAyd2i7nNWnbadwDqm67

RichardHightower and others added 2 commits September 4, 2026 21:09
…01M1QN6CE0P31CYJZFG7K9D3K7)

Three releases shipped a frontend drag fix that could not work. The frontend was
right; the Rust capability file was the block.

Tauri 2 gates startDragging() behind core:window:allow-start-dragging. The
capability granted only core:default, which expands to core:window:default, and
that set is 26 read-only queries plus allow-internal-toggle-maximize. Neither
allow-start-dragging nor allow-toggle-maximize is in it. Every drag call, from
Tauri's own injected drag.js and from our own handler alike, was rejected by the
access control list.

Nothing was logged, because windowDrag.ts swallowed the rejection in an empty
catch. That is why 0.6.2, 0.6.3 and 0.6.4 each looked correct in review and each
failed on a Mac.

The OS used to draw a title bar that dragged for free. It went away in 8fe4093
when titleBarStyle became Overlay, and no code replaced what the OS had done.

- grant core:window:allow-start-dragging and core:window:allow-toggle-maximize
- replace both empty catches with a one-time console.warn naming the capability
  file (Tauri-only path, so the E2E console gate is unaffected)
- unit-test both grants; verified the test fails when the grant is removed

typecheck, guard:client, and 276 unit tests pass. Mac dogfood confirmed: the
window drags from the header.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0124JAyd2i7nNWnbadwDqm67
…01M1QN6CE0P31CYJZFG7K9D3K7)

worklog ia-inventory and ia-render, so the inventory, graph, publish manifest,
traceability page, and the rendered ticket match the new work item.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0124JAyd2i7nNWnbadwDqm67
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant