fix(liturgy): alignment arrow recompute from live DOM on hover#64
Open
anantham wants to merge 1 commit into
Open
fix(liturgy): alignment arrow recompute from live DOM on hover#64anantham wants to merge 1 commit into
anantham wants to merge 1 commit into
Conversation
The hover arrow could land at negative coordinates (off-screen / wrong position) after switching script (IAST ↔ Devanāgarī). Root cause: the `lines` state was populated by computeAlignmentLines during a transient layout — e.g. just after the script swap, before Noto Serif Devanagari fonts loaded — when the new-script word spans had zero size. Cached endpoints had `wordRect.bottom - cRect.top` = (0 - 203) = -203. The hover-time adjustment only patched the Pāli endpoint (when hovering Pāli) or the English endpoint (when hovering English) — it trusted the cache for the other end, so the bad value survived. Fix: in `adjustedLines`, recompute fresh from live DOM whenever there's a hover. By that point the DOM is settled and rects are accurate. The hover-only branch keeps the cost bounded — non-hovered renders still return the cached `lines` (which never paint anyway since AlignmentLines filters by hover). Verified: switching IAST→Deva→IAST and hovering Dhammaṁ / धम्मं in each direction now produces correctly-anchored arrows (164,49) and (127,49) instead of (-24,-203). All 284 alignment-audit tests pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
1 participant
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.
Bug
After switching script (IAST ↔ Devanāgarī) on a chant like
/liturgy/bodhi-sangha/ti-sarana, the hover alignment arrow could land at negative coordinates (e.g. start atM -24,-203) instead of the actual word position. The arc end (English) was correct; only the source-side endpoint was stale.Root cause
computeAlignmentLinesruns in auseLayoutEffectkeyed onactiveScript.lang. When the script swap fired, the new-script spans (Devanāgarī) had zero size momentarily — Noto Serif Devanagari hadn't loaded yet, or the layout hadn't settled.wordRect.bottom = 0produced negative coordinates relative tocRect.top. These bad values stuck in thelinesstate.The hover-time adjustment in
adjustedLinesonly patched ONE endpoint (the hovered one). The other end kept the stale cached value.Fix
On hover, recompute the alignment lines fresh from live DOM. By the time the user is hovering, the DOM has settled. Costs one extra DOM measurement per render-during-hover, which is bounded by hover duration.
The non-hover branch is unchanged (still returns cached
lines), andlinesnever paint when not hovered anyway —AlignmentLinesfilters by hover.Verification
(127, 49)✓(164, 49)✓ (was(-24, -203))(127, 49)✓/liturgy/bodhi-sangha/ti-sarana🤖 Generated with Claude Code