Skip to content

fix: align floating overlays at app zoom - #22

Open
craigk wants to merge 1 commit into
w3dev33:masterfrom
craigk:fix/zoom-overlay-positioning
Open

fix: align floating overlays at app zoom#22
craigk wants to merge 1 commit into
w3dev33:masterfrom
craigk:fix/zoom-overlay-positioning

Conversation

@craigk

@craigk craigk commented Aug 19, 2026

Copy link
Copy Markdown

Summary

Fixes #21

Desktop floating overlays drift right when application zoom is increased above approximately 115%. The issue occurs because Reka/Floating UI computes fixed-position coordinates in viewport space while the portal is rendered inside the zoomed #zoomable-content subtree.

Changes

  • Add an unzoomed #floating-overlay-root outside the zoomed application content.
  • Route dropdown, tooltip, and select portals through the unzoomed root.
  • Apply the current application zoom only to the floating surface, not its positioning wrapper.
  • Add a regression contract covering the shared overlay topology and zoom propagation.

Verification

  • TDD RED: 2 contract failures before the production change.
  • TDD GREEN: 226 Vitest tests passed.
  • Production build passed.
  • Browser geometry probe confirmed the old overlay at 937.5px versus the corrected overlay at 750px for a 750px trigger coordinate.

The type checker still reports two pre-existing bd API typing errors in server/api/bd/list.get.ts and server/api/bd/ready.get.ts.

@w3dev33

w3dev33 commented Aug 19, 2026

Copy link
Copy Markdown
Owner

Thanks for this - genuinely nice work. The diagnosis is spot on (Floating UI computing viewport coordinates while the portal lives inside the zoomed #zoomable-content subtree), the fix is well-scoped, and routing the portals through an unzoomed #floating-overlay-root is the right call. The TDD contract and the geometry probe (937.5px vs 750px) are exactly the kind of verification I like to see.

That said, I'm not going to merge it, and it's worth explaining why. As noted at the top of the README, this project's active development has moved to PaiR. The Beads Task-Issue Tracker is frozen at the last meaningful CLI version it supports (bd 0.49.x / br <= 0.1.33) and I'm no longer cutting new releases for it. Merging even a clean, self-contained fix like this would mean shipping a new build, which is precisely the maintenance track I've closed here.

None of that stops you from carrying the fix yourself: you already have it in craigk/beads-task-issue-tracker, so you can build from your own fork and keep this patch for as long as you're on this codebase. If your fork becomes a maintained continuation for others still on the tracker, I'd be glad to point to it from the README.

So this isn't a reflection on the quality of the PR (which is high) - it's the project status. And if this rendering issue also exists in PaiR, I'd be very happy to look at the same fix over there. Thanks again for taking the time to do it properly.

@craigk

craigk commented Aug 19, 2026

Copy link
Copy Markdown
Author

@w3dev33 NP I totally agree with your comment.
I've been using your project for a while. I figured It was worth offering the fix back to the community in case you or others would benefit.

I hadn't looked at PaiR before last night. I think it has have a similar defect
Thank you for the amount of time you donate to OSS software

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.

Fix desktop floating overlays drifting at app zoom >=115%

2 participants