Skip to content

🛡️ Verify macOS PDF default-handler changes - #62

Merged
JFWooten4 merged 4 commits into
mainfrom
sunburst-pdfverify112
Oct 27, 2026
Merged

JFWooten4 merged 4 commits into
mainfrom
sunburst-pdfverify112

Conversation

@JFWooten4

Copy link
Copy Markdown
Member

Summary

Implement opener-0112, checklist §2.4 “Verify that the default-handler change succeeds.”

  • After NSWorkspace.setDefaultApplication(at:toOpen:) completes without an error, read back Launch Services' actual registered PDF bundle identifier and compare it with the selected application's bundle identifier.
  • Fail with a nonzero exit status and a clear, path-free diagnostic if the PDF association is missing or different. Report success only after verifying that the association took effect.
  • Add independent, read-only macOS synthetic app tests for a matching registration, unchanged registration, different registered application, unreadable registration, explicit non-Brave target, and malformed application bundles.
  • Compile and run the new regression suite in macos-build. Document the verification behavior.

Why

The existing setter treated a successful API callback as proof that macOS changed its default PDF handler. Its callback can succeed without confirming the currently registered association, potentially misreporting success. The new postcondition validates that the exact requested handler is registered.

Scope, coordination, and safety

This PR changes only the setter utility, the macOS CI workflow, its new read-only tests, and a README clarification. It does not alter scanning, quarantine handling, user browser preferences, current PDF associations before explicit installer invocation, or the old no-argument Brave default. Existing setDefaultApplication behavior remains intact.

Concurrent PR #59 independently introduces a read-only CLI for identifying the PDF handler (opener-0108). This PR does not import that unmerged utility or alter its files; it only verifies the result of the existing setter in its own executable, so the two tasks remain independently testable.

Required verification

Run both existing GitHub Actions jobs, scanner-tests and macos-build, on the final integrated PR head; require both to pass, verify mergeability against current main, then squash-merge and independently confirm merged=true and the actual merge SHA.

The configured Codex Pony/Kefania publishing integration is not exposed in this chat; this PR is created through the connected GitHub identity instead.

JFWooten4 and others added 2 commits October 27, 2026 18:32
Read back the Launch Services PDF association after a successful setter callback. Fail closed on a missing or mismatched registration and add read-only synthetic macOS CI coverage.

Co-authored-by: ChatGPT # 6 <noreply@openai.com>
Preserve the independent read-only PDF lookup merged on main and ensure the synthetic app fixtures match valid macOS bundles.

Co-authored-by: ChatGPT # 6 <noreply@openai.com>
Retain the script-style production entrypoint; compile the pure verification helper against synthetic application fixtures without executing the setter. Integrate current main without force-pushing.

Co-authored-by: ChatGPT # 6 <noreply@openai.com>
Bring the active PDF default-handler status workflow into this narrow setter-verification PR without changing its behavior or tests.

Co-authored-by: ChatGPT # 6 <noreply@openai.com>
@JFWooten4
JFWooten4 merged commit 18c7710 into main Oct 27, 2026
2 checks passed
@JFWooten4
JFWooten4 deleted the sunburst-pdfverify112 branch October 27, 2026 22:38
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