Skip to content

Release v0.1.1 and repair macOS overlay reliability - #1

Merged
Ldsystem merged 6 commits into
mainfrom
development
Aug 21, 2026
Merged

Release v0.1.1 and repair macOS overlay reliability#1
Ldsystem merged 6 commits into
mainfrom
development

Conversation

@Ldsystem

Copy link
Copy Markdown
Owner

Summary

  • preserve macOS Accessibility grants with signed bundles and permission rechecks
  • honor the operating-system proxy and wake web-backed accessibility surfaces
  • follow live display topology for selection resolution
  • fix translate-button placement and click routing across mixed-scale secondary displays
  • add a macOS mixed-scale regression fixture and release version 0.1.1

Validation

  • pnpm check: 28 tests passed; typecheck and production build passed
  • pnpm run test:platform: 84 passed, 7 pre-existing manual tests ignored
  • universal macOS bundle: arm64 + x86_64, valid signature, version 0.1.1
  • GitHub Release workflow for v0.1.1 passed
  • user smoke test confirmed the secondary-display problems are fixed

Release

https://github.com/Ldsystem/desktop-translator/releases/tag/v0.1.1

Release bundles were shipped with no signature at all: only the inner
Mach-O carried the linker's ad-hoc signature and Contents/_CodeSignature
was absent. macOS still lists such an app under Accessibility and accepts
the toggle, but it cannot bind the grant to an unsigned bundle, so the
process stays untrusted no matter how often the user grants it.

Ad-hoc sign the bundle through Tauri and fail the release build when the
artifact comes out unsigned. Document that an ad-hoc identity changes per
version, so an update invalidates the previous grant.
reqwest was pulled in with default-features disabled, which silently drops
the system-proxy feature. The client then only read HTTP_PROXY-style
variables, and a GUI app launched from Finder never inherits those. On any
network that reaches Google only through a local proxy, every request went
out direct, hung, and surfaced as a translation timeout.

Restore system-proxy and socks, and add a manual fixture that contacts the
real endpoint with the proxy variables stripped, so only the operating
system's own configuration can satisfy it.
Chromium and applications that host a web view build their accessibility
tree only once a client asks for it. The first read returns an inert tree
with an empty AXSelectedText, so a selection made in Cursor or ChatGPT was
never seen while Office, TextEdit and browsers worked.

Wake the surface under the pointer when the press begins, which gives it
the whole drag to publish its tree, and retry the read once for surfaces
that are still waking when the gesture ends.
The display transforms were captured once while the runtime was built, so
a display attached afterwards was unknown to the adapter. Accessibility
geometry on that display intersected no known bounds, normalisation dropped
every fragment, and the selection resolved to nothing, leaving the built-in
screen as the only place the button could ever appear.

Read the topology from CoreGraphics at each resolution instead. CGDisplayBounds
uses the same top-left logical space the accessibility API reports, and the
window layer positions overlays at logical * scale, so both agree.
macOS does not apply a new Accessibility toggle to a process that is
already running, and this app snapshotted permission only at launch, so
the warning stayed up after the user allowed access. Re-read permission
while Settings is open, start monitoring if the grant takes effect in
place, and tell the user to quit from the menu bar when it does not.
@Ldsystem
Ldsystem merged commit 765529b into main Aug 21, 2026
4 of 5 checks passed
@Ldsystem
Ldsystem deleted the development branch August 23, 2026 13:01
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