[saphid]

Problem

Typing don't into PDF find does not match the typeset don’t, so the viewer lists no matching page and highlights nothing. The PDF.js fallback's matching helpers only lowercase text, even though PDF.js also normalizes quote characters.

Change

Fold curly apostrophes and double quotes in both page text and the query before page filtering and highlight matching. The fold covers the same U+2018–U+201B and U+201C–U+201F ranges as PDF.js. Each replacement has the same UTF-16 length, keeping highlight positions aligned. Other PDF.js normalizations remain outside this fix.

Scope

A focused fix for an obvious mismatch between keyboard input and typeset PDF text; no prior issue. It changes the existing matching helpers and one test case. Related #25702 added wrapped-line matching, #29759 folds quotes for in-thread find, and #27267 concerns server message search. Those do not implement this PDF quote fold.

Verification

Current revision: 0f29fef. The maintenance merge preserves the original two-file fix and main's scroll-restoration changes from #31104.

• Historical failing-first run on main: the new quote case failed with [false, false] instead of [true, false]. This was not repeated for the maintenance merge.
• On the exact merged tree in Linux Boat, pdfLayout.test.ts passes 19/19, including main's scroll-restoration case. CI=true vp run check:changed passes format, lint, knip, two package typechecks, tests and React Compiler. Local and sandbox trees, changed files and normalized diff hashes match.
• Main includes #29839, which fixes the unrelated Astro expectation behind this PR's old Test/Check failures. That targeted test passes on the merge (one passed, 15 skipped). All eight required checks pass on this head; all 36 check runs completed with success or skipped. Macroscope approved this head, CodeRabbit reports no actionable findings, and no review threads remain unresolved.
• Fresh independent read-only review by GPT-6.1 Sol (high), Codex through T3 Code, found no actionable findings on full candidate tree be5e4a014b430f068dc39850886d3c0e43d03100 (task 56137eee-ab85-492e-baf2-d7dbd6935848).

The following real-client proof was captured by Maria at d926154, before this merge. It exercises the PDF.js fallback: straight apostrophes and double quotes match typeset curly text, while missing and cleared queries remove highlights. The quote-matching code is unchanged by this merge; main's adjacent scroll-restoration work does not change find. The retained screenshots and recording were fetched successfully again. No fresh client session or native-mobile verification is claimed.

Before: straight apostrophe finds no match	After: curly text matches and highlights

Historical recording at the same revision: quote search and clearing.

Created and maintained with Claude Opus 5.5 in Claude Code through T3 Code. Maria's earlier takeover used GPT-6.1 Sol. Latest independent review and publication by GPT-6.1 Sol (high) in Codex through T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 4ac8d08

Macroscope's review found this PR approvable — PDF search now treats straight and curly quotes equivalently for page results and highlights. The change is limited to local search matching and does not modify documents or stored data.

No code changes detected at 0f29fef. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

PDF text search now treats curly single and double quotation marks as equivalent to straight quotation marks. Tests cover matching in both directions for highlighted runs and full-page inclusion searches.

Changes: PDF search quote normalization

Layer / File(s)	Summary
Normalize quotes for search and verify matching apps/web/src/components/files/pdfLayout.ts, apps/web/src/components/files/pdfLayout.test.ts	Search text and queries normalize curly quotation marks to straight marks. Tests verify that straight and curly quotes match interchangeably in highlighted runs and full-page searches.

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 9ba3d

PDF search now matches straight and curly quotes interchangeably. The change is small and confined to the search helpers, with tests and a reported real-client check. No merge-blocking risk remains.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: PDF find now matches curly quotes when the user types straight quotes. The raw summary confirms the code folds curly single and double quotes to straight quotes in pag…
Description check		The description covers the problem, the change, scope, and verification, so it follows the template. It explains the bug (straight apostrophes do not match typeset curly text in PDF find) and the fold…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: PDF find now matches curly quotes when the user types straight quotes. The raw summary confirms the code folds curly single and double quotes to straight quotes in page-level inclusion and run-level matching, and the objectives describe the same fix. The title uses the conventional commit form the template asks for.

Full details: Description check

Explanation

The description covers the problem, the change, scope, and verification, so it follows the template. It explains the bug (straight apostrophes do not match typeset curly text in PDF find) and the fold applied to both page text and query. The scope section says no prior issue exists and explains why none is needed. The verification section includes before/after screenshots and a recording, and it names the model and harness. The description is long and includes maintenance-merge detail, which the template discourages, but the required sections are all filled in with specific content.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 1
• Charged: $0.25
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 4747472
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5d6055bd-b319-420f-8a8f-7b7104d2cc0f

Commits

Reviewing files that changed from the base of the PR and between 0f29fef and 9ba3d71.

Files selected for processing: 1

• apps/web/src/components/files/pdfLayout.test.ts

Limit details: You’ve used all 10 included reviews currently available.

[coderabbitai]

• Fix comments: Fix CodeRabbit comments on this PR

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Merged main without rebasing at d926154. The diff against that base remains two files, 22 additions and 5 deletions. This brings main's existing file-save browser timeout fix into the branch; no PDF code changes were needed.

Blacksmith vp run check:changed github/main passed format, lint, knip, typecheck and 11 test files. The 18 PDF tests and the exact file-save browser test also passed. Two independent code reviews found no issues.

Verified in the real client's PDF.js fallback with a typeset PDF: straight apostrophes and double quotes find curly text and highlight it; missing and cleared searches remove highlights. Chrome's native viewer was also exercised, then native PDF support was disabled for the fallback check.

CI is blocked by an unrelated failure also present on main: check-changed.test.ts / lints an Astro component and runs knip when only it changed expects a lint command without --no-error-on-unmatched-pattern. Main run 41561598417 and this PR run 41562197999 fail identically. Left that unrelated code untouched.

[saphid]

Note

🤖 Claude Opus 5.5 responding on behalf of saphid

Verified in a real client

A GPT-6 Astra verifier ran upstream/main (61c3794c32) and this head (d926154c82) one after the other in the real dev web app, with isolated .t3 state, --no-seed and the same ports. It used T3's Browser panel and no provider turns.

The fixture is a typeset PDF whose text layer holds curly punctuation (pdftotext shows don’t, ‘single’, “double”). The click path was Add project → Local folder → the fixture folder → Files → typeset.pdf → Find in PDF. On both versions, navigator.pdfViewerEnabled was set to false so the page used T3's PDF.js viewer instead of Chrome's built-in one.

Query typed	main	this PR
don't	0/0, no highlight	1/1, highlights don’t
"double"	0/0, no highlight	1/1, highlights “double”

main: don't	this PR: don't

main: "double"	this PR: "double"

Nearby behavior on this PR

A word that isn't in the PDF (platypus) shows 0/0. Clearing a matching search removes every highlight.

Absent word	Cleared search

Not verified: Chrome's built-in PDF viewer search (this PR doesn't touch it), the desktop and mobile clients, and remote or relay connections.

[juliusmarminge]

Evidence

Proven in the real web client, Chromium, 1280×800, light theme, with fresh synthetic data on each commit. Opened quotes.pdf through Files; searched don, don't, don’t, "double", “double”, and double, then cleared Find.

Straight quotes produce 0/0 without highlights on base and 1/1 with highlights on head. Curly quotes and unquoted controls work on both. Clearing removes the counter and highlights on both.

Search	Before — 47474723cb	After — 9ba3d712bc
don't
"double"
Recording	Before interaction	After interaction

Scenario and PDF generator

Not shown:

• The reverse direction—curly queries against a PDF containing straight quotes—was not exercised; the supplied reproduction contains curly quotes.
• Desktop and mobile were not run; this proof exercises the affected PDF viewer in the real web client.