Skip to content

[Quality] Scale Finder IPC and selections while keeping menus instant #13

Open

Description

@raiseCatError

Priority: P1 (cross-cutting quality gate)
Parent roadmap: #1
Related: #3, #4, #10 and #11.

Motivation

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.

Activity

  1. raiseCatError commented on Oct 16, 2026

    @raiseCatError
    OwnerAuthor

    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.

  2. raiseCatError commented on Oct 16, 2026

    @raiseCatError
    OwnerAuthor

    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.

  3. raiseCatError commented on Oct 16, 2026

    @raiseCatError
    OwnerAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions