Repository navigation
Fixes from live-testing the Rust steps: form fields in Compare, worker error handling, no worker on mobile - #1016
Open
DutchSailor wants to merge 4 commits into
Open
DutchSailor wants to merge 4 commits into
DutchSailor wants to merge 4 commits into
Conversation
The mobile apps run in Tauri but have no PDFium worker. The worker path only checked for Tauri, so every page pair on Android made a compare_pixel_pair call that failed with "worker pool not ready" before the JS pipeline ran. Pass isMobile() to createRustCompare so the path is off there, like the PDFium render path (heeftRustRenderer).
A render or region answer with ok:false (for example PDF_OUTPUT_LIMIT on a large sheet at a high zoom) means the exchange went fine and the worker is healthy. The pool still treated it as a crash: it killed and respawned the worker, retried the render cold on a second worker (which failed the same way and was restarted too) and after three such answers in 30 s marked the worker DeadPermanent. Requests queued on that worker, such as snap geometry, failed with PDF_WORKER_UNAVAILABLE and fell back to JS. Type these answers as WorkerReported: no restart and no retry on another worker. Broken exchanges (EOF, timeout, garbage) still restart the worker.
pdf.js draws form field appearances with intent 'display', so a changed field value is a change in the JS pipeline. PDFium draws fields only in the form pass (FPDF_FFLDraw), which the matrix render used for compare tiles skips. On desktop a changed value in a title block was therefore not reported, while the overlay showed the new value and the web version reported it. On a page with widget annotations a tile is now rendered as the whole page at scale with a shifted origin, with annotations and form data. Pages without fields keep the matrix route.
This was referenced Nov 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes found while live-testing the Rust steps of #1014 on a release build, with real drawings, form fields, the real UI and the fallback paths.
What changes
ok:falseanswer (for examplePDF_OUTPUT_LIMITon an A0 page at high zoom) was treated as a crash: the pool killed and restarted the worker, retried cold on a second worker, and marked workers permanently dead after three times, so queued snap requests fell back to the slow JavaScript path. This behaviour predates Rust steps 1: monochrome recompression, Compare pixels and snap geometry in Rust #1014. Live on a heavy sheet: before, 8 restarts and 2 workers permanently dead in three runs; after, 0 restarts.Verification
cargo test -p pdfium-worker: 65 pass (two new worker tests for form fields)--no-run; the app's lib test executable does not start on this machine)node --test js/compare/rust-compare.test.mjs: 5 passNot verified
🤖 Generated with Claude Code