Pre-push review: T-1751 stale search highlights after reload

diff --git a/prism/Views/DocumentScrollContent.swift b/prism/Views/DocumentScrollContent.swiftindex c50a82c..4f9d4db 100644--- a/prism/Views/DocumentScrollContent.swift+++ b/prism/Views/DocumentScrollContent.swift@@ -175,8 +175,10 @@ struct DocumentScrollContent: View {         }         // Search highlights (Req 6.1/6.2/6.3/7.2, T-1680): re-push whenever the         // coordinator's debounced query, per-block counts (recomputed on block or-        // comment-visibility changes), or current-match selection change. Both layouts-        // mutate the same SearchCoordinator, so this single feed covers the inline bar+        // comment-visibility changes), current-match selection, or the parse+        // revision change — the payload is keyed by content-hash block DOM ids, so+        // a reparse invalidates it even when the native numbers are equal (T-1751).+        // Both layouts mutate the same SearchCoordinator, so this single feed covers the inline bar         // and the compact overlay; prism-search.js also scrolls the pushed current         // match into view. Clearing the search pushes the empty payload, which clears         // the page's highlights.@@ -308,21 +310,10 @@ struct DocumentScrollContent: View {         )     } -    /// The coordinator state the search-highlight push depends on; a change to any+    /// The state the search-highlight push depends on; a change to any     /// field re-pushes `setSearchState` (see the `.onChange(of: searchStateKey)`).-    private var searchStateKey: SearchStateKey {-        SearchStateKey(-            query: context.session.search.activeSearchQuery,-            matchCounts: context.session.search.matchCountsPerBlock,-            currentIndex: context.session.search.currentGlobalMatchIndex-        )-    }--    /// Equatable identity for the search-highlight push trigger.-    private struct SearchStateKey: Equatable {-        let query: String-        let matchCounts: [Int]-        let currentIndex: Int?+    private var searchStateKey: WebSearchStateKey {+        WebSearchStateKey(session: context.session)     }      /// The view-world palette inputs the rendered document needs: the@@ -342,6 +333,33 @@ struct DocumentScrollContent: View {     } } +/// Equatable identity for the search-highlight push trigger (T-1680): the state+/// the `setSearchState` payload is derived from. A change to any field means the+/// payload the page holds is out of date and must be re-pushed. Top-level (like+/// `WebPaletteFeed`) so tests can pin exactly when a re-push must fire.+///+/// `parseRevision` is here because the payload is keyed by content-hash block+/// DOM ids (`BlockDOMID`), making it a function of block identity as well as of+/// the coordinator's native state. A reload can rewrite matching block text+/// while leaving the query, per-block counts, and current index all equal — the+/// reload then replays the coalesced snapshot, so without a block-identity+/// token the page would keep highlight instructions addressing DOM ids that no+/// longer exist (T-1751).+struct WebSearchStateKey: Equatable {+    let query: String+    let matchCounts: [Int]+    let currentIndex: Int?+    let parseRevision: UInt64++    @MainActor+    init(session: DocumentSession) {+        query = session.search.activeSearchQuery+        matchCounts = session.search.matchCountsPerBlock+        currentIndex = session.search.currentGlobalMatchIndex+        parseRevision = session.parseRevision+    }+}+ /// The palette state the document surface feeds to the web renderer from the view /// world. Grouped into one `Equatable` value so a single `.onChange` covers every /// input and they are always pushed as a consistent pair (T-1829).

diff --git a/prismTests/WebRendering/WebSearchReloadTests.swift b/prismTests/WebRendering/WebSearchReloadTests.swiftnew file mode 100644index 0000000..0252747--- /dev/null+++ b/prismTests/WebRendering/WebSearchReloadTests.swift@@ -0,0 +1,171 @@+//+//  WebSearchReloadTests.swift+//  prismTests+//+//  T-1751 regression tests: search highlights must survive a reload that changes+//  block content without changing the native search numbers.+//+//  The search-highlight payload (`setSearchState`) is keyed by occurrence-+//  qualified block DOM ids (`b-{contentHash}-{sourceIndex}`), so it is a joint+//  function of the SearchCoordinator's native truth AND block identity. The+//  view's re-push trigger (`DocumentScrollContent.searchStateKey`) only modelled+//  the native half: query, per-block match counts, current match index. When a+//  reload (file change, URL refresh) rewrites matching block text but leaves+//  those three fields equal, no fresh push fires — and the reload's coalesced+//  snapshot replay re-sends the stale payload, addressing DOM ids that no longer+//  exist in the re-emitted document. Native counts stay correct while the page+//  shows no highlights.+//+//  These tests pin the two halves of the fix:+//   1. `WebSearchStateKey` must change when a reparse changes block identity,+//      even with identical query/counts/current index.+//   2. Driving the production push path with the view's gating ("push only when+//      the key changed") must leave the controller's coalesced snapshot — the+//      exact state a reload replays — addressing the NEW block DOM ids.+//++import Foundation+import Testing+@testable import prism++@Suite("T-1751 search highlights across reload", .serialized)+@MainActor+struct WebSearchReloadTests {++    /// Original document: matches in two paragraphs, none in heading or closer.+    /// Per-block counts: [0, 1, 2, 0].+    private static let originalMarkdown = """+    # Reload haystack++    First paragraph mentions a needle once.++    Second paragraph has a needle and another needle.++    A closing paragraph with no match at all.+    """++    /// Reloaded document: both matching paragraphs are reworded (new content+    /// hashes, therefore new DOM ids) while keeping the same block structure and+    /// the same per-block match counts [0, 1, 2, 0], so the coordinator's query,+    /// counts, and current index are all unchanged after the reparse.+    private static let reloadedMarkdown = """+    # Reload haystack++    A rewritten opening paragraph still mentions a needle once.++    The rewritten second paragraph has a needle and another needle in it.++    A closing paragraph with no match at all.+    """++    /// Builds a session with the original content, an active query, and a+    /// selected current match — the state a reader is in mid-search.+    private func makeSearchingSession() async -> DocumentSession {+        let session = DocumentSession(clipboardContent: Self.originalMarkdown)+        await session.parseContent()+        session.search.setActiveSearchQueryForTesting("needle")+        session.search.navigateToMatch(at: 1)+        return session+    }++    @Test("the push trigger changes when a reparse changes block identity")+    func searchStateKeyChangesWhenBlockIdentityChanges() async throws {+        let session = await makeSearchingSession()+        #expect(session.search.matchCountsPerBlock == [0, 1, 2, 0])++        let countsBefore = session.search.matchCountsPerBlock+        let indexBefore = session.search.currentGlobalMatchIndex+        let domIDsBefore = Set(BlockDOMID.map(blocks: session.parsedBlocks).map(\.domID))+        let keyBefore = WebSearchStateKey(session: session)++        await session.reloadContent(markdownString: Self.reloadedMarkdown)++        // Precondition of the bug: the reparse changed block identity (the two+        // matching paragraphs have new content hashes)…+        let domIDsAfter = Set(BlockDOMID.map(blocks: session.parsedBlocks).map(\.domID))+        #expect(domIDsAfter != domIDsBefore, "the reload fixture must change block DOM ids")+        // …while the native search numbers are unchanged.+        #expect(session.search.matchCountsPerBlock == countsBefore)+        #expect(session.search.currentGlobalMatchIndex == indexBefore)++        // The payload is derived from block identity too, so the trigger key+        // must differ — equal keys mean no re-push and a stale snapshot replay+        // after the reload (T-1751).+        let keyAfter = WebSearchStateKey(session: session)+        #expect(+            keyAfter != keyBefore,+            "search push trigger did not change across a reparse that changed block ids"+        )+    }++    @Test("after a reload the coalesced snapshot addresses the new block DOM ids")+    func snapshotUsesFreshDOMIDsAfterReload() async throws {+        let session = await makeSearchingSession()+        let settings = AppSettings()+        let controller = WebDocumentControllerFactory.make(session: session, settings: settings)++        // This manually mirrors DocumentScrollContent's search wiring — the+        // initial `pushSearchState`, the `.onChange(of: searchStateKey)`+        // changed-key gating, and the `.task(id: WebLoadKey(...))` load — call+        // for call. If the view's sequence gains a step, this must gain it too.+        //+        // The sequence below drives one representative interleaving (push,+        // load, reload → gated push → load). SwiftUI does not guarantee this+        // exact order between the onChange push and the load task, and the+        // design does not require it: `load` stamps the generation at dispatch+        // time and the reload replays whatever `latestSnapshot` then holds+        // (last write wins), so a reversed ordering converges to the same+        // final snapshot and the assertions below hold either way.+        var lastPushedKey = WebSearchStateKey(session: session)+        WebDocumentControllerFactory.pushSearchState(+            to: controller, session: session, settings: settings+        )+        controller.load(+            documentURL: WebDocumentControllerFactory.documentURL(+                session: session, parseRevision: session.parseRevision+            ),+            parseRevision: session.parseRevision+        )++        // External change → reparse with unchanged query/counts/current index.+        await session.reloadContent(markdownString: Self.reloadedMarkdown)++        // Mirror the view's `.onChange(of: searchStateKey)` gating exactly: a+        // push happens only when the key changed. Before the fix the key is+        // equal, so nothing re-pushes.+        let key = WebSearchStateKey(session: session)+        if key != lastPushedKey {+            lastPushedKey = key+            WebDocumentControllerFactory.pushSearchState(+                to: controller, session: session, settings: settings+            )+        }++        // The parseRevision bump reloads the page, which replays the coalesced+        // snapshot — whatever searchStateJSON it holds is what the page gets.+        controller.load(+            documentURL: WebDocumentControllerFactory.documentURL(+                session: session, parseRevision: session.parseRevision+            ),+            parseRevision: session.parseRevision+        )++        let json = try #require(controller.latestSnapshot.searchStateJSON)+        let root = try #require(+            try JSONSerialization.jsonObject(with: Data(json.utf8)) as? [String: Any]+        )+        let payloadBlocks = try #require(root["blocks"] as? [String: Any])+        #expect(!payloadBlocks.isEmpty, "an active query must produce a non-empty payload")++        // Every payload key must address a section that exists in the+        // re-emitted document. Before the fix the snapshot still carries the+        // pre-reload DOM ids, which match no element (T-1751).+        let freshIDs = Set(BlockDOMID.map(blocks: session.parsedBlocks).map(\.domID))+        for domID in payloadBlocks.keys {+            #expect(+                freshIDs.contains(domID),+                "replayed search snapshot addresses a DOM id that no longer exists: \(domID)"+            )+        }+    }+}

diff --git a/CHANGELOG.md b/CHANGELOG.mdindex 9d6c8b3..b915337 100644--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -18,6 +18,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0  ### Fixed +- Search highlights survive a reload that rewords the matching text (T-1751). If a file changed on disk — or a URL document was refreshed — while a search was active, and the edit reworded the matching passages without changing how many matches each block had, the reloaded page showed stale highlights or none at all, while the match counter and navigation stayed correct. Highlights are addressed to blocks by their content, which the rewrite changed, but the trigger that re-sends them only watched the match numbers, which the rewrite did not. The trigger now watches block identity as well, so the reloaded page is sent highlights that address the blocks it actually shows. - Writing a footnote reference so readers can see it now shows it (T-1716). `` `[^1]` `` in inline code came out as an empty code span followed by a tappable footnote badge, so a document explaining footnote syntax could not display it — and the text on screen no longer matched the text you could select or copy. Inline code now renders the reference exactly as written, and so does the other way of writing one literally, `\[\^1\]`, whichever order the two forms appear in and however closely they sit together. Two more faults went with the same change: text after a reference followed by four or more spaces (`word[^1]     more`) was silently dropped (T-1945), and emphasis wrapped around a reference (`*em [^1] end*`) leaked literal asterisks instead of italicising. The space separating a badge from the following word is rendered again too, so selecting the text after a badge selects what you see. A reference written inside a link address, inside an image's alt text, or as HTML character references (`[^1]`) stays literal text as well. A link whose caption contains a reference — `[the citation [^1]](https://example.com)` — now renders as a working link showing the reference as written: a badge cannot go there, because a footnote badge is itself a link and one link cannot sit inside another. Before this release that caption was not a link at all; the reference broke it into plain text either side of a badge. Footnotes inside list items and table cells still carry the separate note-anchoring limitation tracked under T-1941. - The **+** button for adding a note to a block is easier to see on the dark themes (T-1980). It rests at a deliberately low opacity so it does not compete with the text beside it, but that single value was tuned for the light themes: the glyph is drawn in the same muted grey the themes use for de-emphasised text, which fades much faster against a dark background than a light one. Prism Dark and Classic Dark now rest a little brighter. It was hardest to spot on a Mac, which sat at the dimmest setting and relied on hovering to bring the button up — iPhone and iPad were already lifted, since there is no pointer to hover with. The light themes are unchanged, hovering still brings the button to full strength, and turning on the system **Increase Contrast** setting still removes the fading entirely. - The **Body Font** you choose in Settings now applies to the document (T-1827), and iOS **Larger Text** (Dynamic Type) now scales it (T-1828). Since the WebKit rendering cutover the document was drawn at a fixed system font and a fixed base size: picking a body font moved only the preview in Settings, and raising Larger Text scaled the app's toolbars, sidebars, and panels while paragraphs, headings, lists, and tables stayed put. Body text, headings, lists, and tables now use the selected family — code blocks and inline code stay monospace — and the document's base size follows the system text size, combined with the in-app Text Size slider rather than replaced by it. Both follow changes live, without reloading the document, and both survive a WebKit process recovery. Because a size or family change reflows the text, where you were reading can shift on screen; re-anchoring the reading position across a reflow is tracked separately. A font that is no longer installed falls back to the system font instead of failing, and a font name is applied as text only, so it cannot alter the document's styling. On Mac, document text also returns to the 15pt reading size the app used before the rendering engine changed — the engine cutover had left it at the iOS size, which is larger than intended on a Mac and left no room below the Text Size slider's 80% minimum. Mac documents now follow the system Text Size setting as well.