fix(navigation): open the correct chapter/verse when deep-linking into a not-yet-open book (#996)#1025
Open
sampjvv wants to merge 1 commit into
Open
fix(navigation): open the correct chapter/verse when deep-linking into a not-yet-open book (#996)#1025sampjvv wants to merge 1 commit into
sampjvv wants to merge 1 commit into
Conversation
…d open (#996) Clicking a text-only cell in the export wizard's audio-stats popover is supposed to open the source+target editors at that cell's chapter/verse. When the book was not already open, it instead opened at chapter 1. openCodexDocumentWithSourcePair waited for the source pane's webview to be ready but not the target .codex pane. Callers publish the navigation jump (the `cellToJumpTo` workspace-state key) immediately after this helper returns; the per-editor jump listener is registered while the editor resolves, and waitForWebviewReady only returns once a pane has signalled ready. With the target pane not waited for, a cold-opened editor could miss the jump and fall back to its default page (chapter 1). When the book was already open (warm), both panes were ready, so it worked. Resolve the provider once and wait for BOTH panes (source and target) to be ready before returning, in the normal path, the source-failed fallback, and the no-workspace path. Cold-open now behaves like warm-open. Fixes #996 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
What & why
Fixes #996 — "When clicking on cells without audio, the proper chapter doesn't open."
In the export wizard's Step 1 audio-stats popover (which lists a book's text-only cells), clicking a cell is supposed to open the source+target editors and navigate to that cell's chapter/verse. When the book was not already open, it instead opened at chapter 1 (e.g. clicking 11:20 → chapter 1). When the book was already open, it worked — which made it intermittent.
Root cause (cold-open race)
openCodexDocumentWithSourcePairopened the source pane andawaitedwaitForWebviewReady(source), then opened the target.codexpane without waiting for it. Callers (the export popover viajumpToCellInNotebook) publish the navigation jump — thecellToJumpToworkspace-state key — immediately after this helper returns.The per-editor
cellToJumpTolistener is registered while the editor resolves, andwaitForWebviewReadyonly returns once a pane has signalled ready (i.e. after it resolved + registered its listener). With the target pane not waited for, a cold-opened editor could miss the jump and fall back to its default initial page (chapter 1). The general jump path was hardened for the search view back in March, but this helper's missing target-pane wait left the export deep-link (added shortly before this was reported) exposed.Fix
Resolve the editor provider once and
await waitForWebviewReadyfor both panes (source and target) before returning — in the normal path, the source-failed fallback, and the no-workspace path. Cold-open now behaves like the working warm-open.The helper is shared (navigation sidebar, NewSourceUploader "Start translating"), so they get the same small target-readiness wait and the same cold-open race protection; no other behavior change.
Changes
src/utils/openCodexDocumentWithSourcePair.ts— wait for the target pane's webview ready (plus a single provider lookup + smallwaitForPaneReadyhelper).Testing
npm run compileclean; typecheck clean for the changed file.🤖 Generated with Claude Code