You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Quality] Scale Finder IPC and selections while keeping menus instant #13
Early Tuck authenticated tuck://perform requests limited selected paths to 16 and encoded file paths in a URL. Large selections and multiple new actions make that limit and menu responsiveness important. We must not silently truncate the user's selection or let Finder block on slow tasks.
Scope
Inspect current selection capture and IPC limits, the exact live code rather than older reports. If a 16-path cap remains, replace silent truncation with a safe, scalable local handoff or explicit limit/error.
Preserve the existing authenticated helper/extension boundary, request freshness/replay protection and path validation. Never use unsigned world-readable temp payloads.
Avoid expensive metadata, codec probing, network work or filesystem recursion while Finder constructs a context menu.
Make menu availability checks contextual but inexpensive; defer validation/execution until helper receives the request.
Account for multi-volume sources, macOS sandbox access, Finder restarts, huge selections, Unicode and very long paths.
Isolate heavy encoders and file operations behind jobs with bounded memory/parallelism. Prefer no long-lived heavy background component when idle.
Acceptance criteria
A 1, 16, 17, 100 and 1,000 item selection either processes everything safely or explicitly explains a documented user-facing limit. Nothing disappears silently.
A selection spanning directories/volumes and containing long/Unicode filenames is passed accurately.
Invalid/malicious IPC requests are rejected; signatures/keys/full sensitive URLs aren't logged.
Menu creation latency is measured on a representative directory (warm and cold), and the implementation documents a reasonable performance budget.
Finder menu remains responsive even if external encoders, mounted volumes or the app helper are unavailable.
No regression of menu enable/reorder settings or desktop/selection targeting.
Verification
Automated IPC boundary tests, fuzz/boundary payloads, benchmark selection-size scaling, physical Finder operations and constrained 8 GB RAM profiling. External scratch must be on a verified mounted volume and should fail closed rather than fall back internally.
Partial implementation still applies: main supports 256 selected paths and a 64 KB signed IPC payload with explicit user-facing warnings rather than silent truncation. Authenticated nonce/replay behavior has automated tests. A scalable manifest/handoff for more than 256 paths, measured Finder menu latency and real multivolume/long-path physical tests remain outstanding. Recent PRs #17–#19 did not change this limit.
PR #20 merged: removed old compression 16-path truncation, supported ZIP up to the authenticated 256-path limit, and made signed requests >256 fail explicitly instead of dropping paths. Verified using a 17-input compression regression and 17-item ZIP archive test on macOS. The 256-path and 64KB IPC caps still apply; >256 handling/performance remains roadmap work.
Code gate complete, physical performance gate remains:PR #33 added explicit IPC regression checks for 1,16,17,100,256,257 and 1,000 selections, Unicode and >64 KB payloads. <=256 represent all paths; oversized requests fail explicitly (not truncated). The Finder extension now logs per-menu elapsedMs with only counts and timing, not private paths. Hosted macOS Swift 6 suites and production build passed. Still open: measure actual warm/cold Finder timings at representative selections and 8 GB memory usage, and physical multi-volume/large-selection QA. Limit remains 256 paths / 64 KB.
Activity
raiseCatError commentedon Oct 16, 2026
Partial implementation still applies: main supports 256 selected paths and a 64 KB signed IPC payload with explicit user-facing warnings rather than silent truncation. Authenticated nonce/replay behavior has automated tests. A scalable manifest/handoff for more than 256 paths, measured Finder menu latency and real multivolume/long-path physical tests remain outstanding. Recent PRs #17–#19 did not change this limit.
raiseCatError commentedon Oct 16, 2026
PR #20 merged: removed old compression 16-path truncation, supported ZIP up to the authenticated 256-path limit, and made signed requests >256 fail explicitly instead of dropping paths. Verified using a 17-input compression regression and 17-item ZIP archive test on macOS. The 256-path and 64KB IPC caps still apply; >256 handling/performance remains roadmap work.
raiseCatError commentedon Oct 16, 2026
Code gate complete, physical performance gate remains: PR #33 added explicit IPC regression checks for 1,16,17,100,256,257 and 1,000 selections, Unicode and >64 KB payloads. <=256 represent all paths; oversized requests fail explicitly (not truncated). The Finder extension now logs per-menu
elapsedMswith only counts and timing, not private paths. Hosted macOS Swift 6 suites and production build passed. Still open: measure actual warm/cold Finder timings at representative selections and 8 GB memory usage, and physical multi-volume/large-selection QA. Limit remains 256 paths / 64 KB.