[LabDennis]

What this changes

Refs #307. Reuse the unmodified source parse during document inspection and bound background PDF preparation to the next result the UI can accept. Later paths stay unread while a prepared result, password prompt or other modal interaction waits. Up to 64 requests remain accepted.

The desktop enables background opening before startup files and session restoration. Request-owned continuations preserve startup view options, restored pages and focus, requested tools, remote destinations, recovery metadata and password retries. Failed opens cannot run a tool on a different tab. Results prepared under stale JavaScript or certificate-trust settings are prepared again before registration.

Inspection only shares the COS parse for the same unmodified source allocation; edited objects, trailers or encryption force independent source inspection. Inspection caches remain independent and existing stream limits are not raised. Exact structural signed-file guards include adopted fields and standalone timestamps.

The current branch retains upstream #1895's eager signature validation, rendered verdicts, status banner, trust refresh and signed snapshots. It does not defer signature details or require opening the Signatures panel to validate them. Source and UI completion logic are separated into small modules; CLI/MCP opening remains synchronous.

Source work and remaining scope

Credit to @cyfung1031's source proposals: #1527 (eaa0c275c31effe8cc0a5e1423045ae809fdeb77) for shared parsing, #1434 (a4cdc2d4bb1423cb00560b5092be4f1f14d04537) for deferred marker/link indexes, and #1493 (355d4c5be83bf208565b9a7aaf295a3735ceed95) for background preparation. The latter two have landed upstream; this branch preserves them and adds the remaining integration and admission control. #1465's deferred-signature proposal is no longer included because current upstream needs those verdicts during rendering.

This is a partial improvement for #307, not a claim to finish M1. Cold-cache opening and first rendered frame remain unmeasured on this rebased tree. Admission control is not a global byte/RSS budget: an active parse is not interrupted, and already-open documents and caller-owned buffers are outside the bound. Image/text conversion still runs on the UI thread after reading. Compact xref storage remains separate work.

Earlier benchmark measurements were made on older implementations and have not been repeated on this tree; they are not performance claims for the current head.

Validation

Windows validation against upstream f0c9901: 276 engine unit tests, 448 UI unit tests and 71 integration tests across picker, recovery, reload, signing and signer-trust flows passed. The engine and UI unit suites each retain one existing ignored test. Scoped all-target Clippy (--no-deps, warnings denied), UI WASM, desktop Cargo check, formatting, worktree-specific assets and layering checks passed. Hosted CI must complete independently.

No new assets, fonts or dependencies. Control/MCP remain opt-in; source confinement is unchanged. Roadmaps and local agent instructions are unchanged.

[cyfung1031]

excellent!!

[FredApps]

While investigating CI failures in unrelated PRs, I reproduced two regressions on current main: open_then_run loses its requested command after asynchronous preparation, and startup bytes can be consumed while a local password retry is still pending. Replacing fixed-frame waits with condition-based waits exposed both as actual behavior failures rather than only timing-sensitive tests.

I see this PR already covers those continuation/ordering paths, so I am holding a separate narrow fix to avoid overlapping production changes. Useful regression cases are: tool execution exactly once after plain/encrypted opening; no tool execution on wrong password or cancellation; successful/failed text/image conversion; and startup bytes remaining queued while local password preparation is held behind a deterministic barrier. The six affected integration binaries also need completion-aware waits if they exercise the asynchronous mode.

Our independent narrow patch plus those waits passed 2,996 tests (13 existing ignored) and the workspace gates on base fff985f. That is evidence for the regression cases, not validation of this PR’s full integration. Current native CI in #1672 stops at the open-then-tool test before reaching the unrelated extent regression.

[LabDennis]

should be ok now

[FredApps]

Re-reviewed 6d1f5c2. The two continuation/ordering concerns are addressed: deferred tools follow the correct open request, and startup bytes stay queued through pending password preparation. I also checked lazy-index invalidation, the independent COS inspection view and pre-validation signed-document guards.

Independent Linux headless validation at this exact head: 18 open-worker tests, 36 picker tests, both deferred-tool/recent-open command regressions, and 9 engine/COS/render regressions passed (65 total). Hosted Windows/Linux/WASM checks were also green at this head.

No further blocker found in the reviewed scope. This does not claim a cold-cache large-file first-frame benchmark or native interactive validation; the documented conversion and M1 scope limits remain.

[FredApps]

Rechecked the upstream-sync delta at exact head 28d87d6fd2a680f8aa50c77807e020c82bcc9f61. No new blocker found in the reviewed opening/continuation scope.

Fresh independent Linux validation at this head passed 28 worker tests, 2 file-watcher regressions, all 36 picker tests, and the deferred-tool/recent-file command regressions: 68 passed, zero failures or ignored tests. The checkouts remained clean and assertions were unchanged. My earlier source-isolation, lazy-index and signed-file review still applies; these fresh tests do not repeat the full workspace or establish cold-cache first-render performance.

[FredApps]

CI follow-up: the full hosted run has now failed on both Ubuntu and Windows in the two encrypted recovery tests, outside the targeted batch above: encrypted_documents_are_autosaved_encrypted_and_recovered_with_the_password and an_encrypted_snapshot_without_metadata_still_requires_its_password. Both fail locating Role::PasswordInput after the password-prompt state predicate. Run.

I am checking whether the synchronous recovery path makes that predicate true before the password modal is drawn. This is not yet evidence of an encrypted recovery behavior failure, but CI is not clear until the distinction is verified.

[FredApps]

@LabDennis Confirmed the cause at 28d87d6: these two failures are password-modal presentation timing. Unchanged recovery tests reproduce 9 passed / 2 failed; main e4028b3 passes all 11.

Keeping every original assertion and waiting for query_by_role(Role::PasswordInput) to return a present, enabled control before typing makes all 11 pass, both normally threaded and sequentially. In both failing cases the field appeared two layout frames after password_prompt was set. Restoring the original tests reproduces both failures again.

Please use a bounded condition-based wait for that interactive field at the two query sites, rather than adding a fixed frame count. The existing Cancel-button wait in the same recovery test file follows this pattern. No production recovery change was needed in this diagnostic, and the encrypted bytes, dirty state, page counts, metadata and saved-path assertions all remained intact. Diagnostic changes have been restored; this still needs the test adjustment and a fresh CI run.

[FredApps]

Rechecked the recovery-test adjustment at exact head f87b2c7. The two sites now wait for a present, enabled PasswordInput with a 30-second bound, and the original behavioral assertions remain intact. This addresses my timing finding without changing production recovery code.

The fresh hosted CI run now passes Ubuntu, Windows, WASM and dependency checks (fuzz skipped): https://github.com/storytold/pdfcraft/actions/runs/38523965264 . My recovery-test CI blocker is cleared. This update is source review plus verification of hosted checks; I did not rerun a separate local suite on this new head. The previously documented M1/performance scope limits remain.

[FredApps]

Rechecked the squashed/upstream-sync head 7cc67ec against the previously reviewed f87b2c tree. The actual file-tree delta is the queue backpressure follow-up, its tests/docs and the upstream version bump; the earlier integration is retained. I found no new blocker in the reviewed request-ordering/backpressure code.

Fresh independent Linux validation at this exact head passed 101 tests: 31 open-worker, 11 recovery, 36 picker and 23 command tests, with zero failures or ignored tests. This covers held-result backpressure, paths staying unread behind a password modal, security-policy re-preparation priority, and open-then-tool continuations. The bounded recovery waits and existing behavioral assertions remain intact; the checkout stayed clean.

Hosted CI is still pending, so this does not claim all gates are green. This is scoped headless validation, not a new full-workspace run, native desktop benchmark, or cold-cache/first-render measurement. The documented M1 limits still apply.

[FredApps]

CI follow-up: the dependency gate now fails because Cargo.lock contains rustls 0.23.45, flagged by today's RUSTSEC-2026-0346 through 0349. The audit requires >=0.23.46; bans, licences and sources pass. This is inherited from current main 9931329, which locks the same version/checksum, rather than a change introduced by this PR.

Existing PRs #2181 and #2216 already contain the minimal rustls 0.23.46 version/checksum update. Once one is merged, please update this branch from main and run fresh CI rather than suppressing the advisories or duplicating the fix. The 101 focused tests reported above remain valid for the reviewed head, but do not clear this separate dependency gate.

Failed job: https://github.com/storytold/pdfcraft/actions/runs/38604055308/job/115990282408

[LabDennis]

Updated onto f0c9901 while retaining upstream #1895's eager signature validation, rendered verdicts, trust refresh and signed snapshots. Removed the obsolete deferred-signature behavior and corresponding claims from the PR description. The remaining change shares source inspection and adds UI-driven admission/backpressure and request-owned opening continuations.

The rebase keeps the current file-picker admission guard: an already-prepared document cannot replace the recipient of an open picker. The upstream picker tests reproduced the regression before that guard was restored. Queue-bound fixtures now use distinct paths to respect upstream deduplication; the recovery test releases its store clones before checking that the instance-lock directory is empty.

Windows validation against upstream f0c9901: 276 engine unit tests, 448 UI unit tests and 71 integration tests across picker, recovery, reload, signing and signer-trust flows passed. The engine and UI unit suites each retain one existing ignored test. Scoped all-target Clippy (--no-deps, warnings denied), UI WASM, desktop Cargo check, formatting, worktree-specific assets and layering checks passed. Hosted CI must complete independently.

The PR remains one focused commit. Earlier measurements were not rerun on this tree; the documented M1/global-memory/cold-cache scope limits remain. Roadmaps are unchanged.

[FredApps]

Scoped revalidation at c348bf4 after the upstream refresh. I reviewed the current production/test delta and found no new blocking issue in the signature-image loading and admission paths.

Independent checks passed: engine library276/1 ignored; UI library456/1 ignored; pickers36, recovery12, reload11, signing UI11, signer trust1; COS2 and render2 regressions; signing crate117/1 ignored. Formatting, affected strict Clippy, UI/web WASM, assets and layers passed. Seven WASM dead-code warnings remain. The initial unchanged font test failed with the validation wrapper setting PDFCRAFT_SYSTEM_FONTS=0; after unsetting that variable only for child processes, the focused test and complete UI suite passed. No code or assertion changes were made; all1429 tracked hashes matched and final Git status was clean. Engine was not rerun during that second pass. Hosted CI38877148112 is successful, fuzz skipped.

These are scoped correctness checks, not fresh cold-cache performance, native macOS/M1 testing or proof that every global memory-budget concern is solved.