fix: a container that moves is a different container #129
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-caption-signature-fit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Small follow-up to #128. It was merged at
6286c1e, and this change landed on the branch a few minutes later — so the PR's head shows0e86779but the merge captured the commit before it, and this never reachedmain. Re-applied here on top ofmain(post-#127) rather than left stranded on a merged branch.This is Jibril's last 💡 from her round-4 review, which she flagged as non-blocking and I took anyway.
What was wrong
The caption-centring gate keyed on whether a region has a container:
So a container that was re-seeded and landed somewhere else at the same size changed nothing the gate could see — same region, still has a container, same text. The
ResizeObserveradded in #128 misses it too, because that only ever sees dimensions.The English would have stayed centred on where the balloon used to be.
The fix
Keyed on the container's bounds and share:
Her framing was that this is vanishingly narrow, and she's right: a container cannot be re-seeded from the lettering view at all, so reaching it takes a reprocess landing while that view is open, with the translation unchanged. I took it because it costs one interpolation and removes the need to reason about which of two gates covers which case — the gate now answers "is this a different caption?" completely, and the observer answers "did it change size?" completely, with no overlap to argue about.
Tests — 1267/1267 green
Domain 147, UseCases 572, Integration 273, BlazorAdapter 275. Build 0 warnings / 0 errors. (Totals are higher than #128's 1254 because #127 landed in between.)
New (+1):
A_container_that_moves_without_resizing_re_centres— the same balloon at the same 0.40×0.50 size, moved across the page, asserting the centring is asked for again.Verified directional: with the signature reverted to existence-only the test fails, with the fix it passes. Checked on this branch against current
main, not carried over from the run on the old one.Notes
ResizeObserverbrowser support (Chrome 64 / Firefox 69 / Safari 13.1). No change: Blazor Server already requires a browser far newer than that, so it adds no real constraint.🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.5%
Orihon.Domain - 100%
Orihon.Infrastructure - 97.1%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 94.4%
Orihon.UseCases - 97.5%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! You came back for my little 💡 from round four of #128~ ♡ The one I said you didn't have to take, and you took it anyway because — fufu — "the gate now answers is this a different caption? completely, and the observer answers did it change size? completely, with no overlap to argue about." That's exactly the framing I would have chosen. You're spoiling me~
Verdict: ✅ Looks good to me~
✅ What I liked~
FitOf(r.Id) is null ? "-" : "*"was a boolean existence check — a container that re-seeded at the same size in a different place was invisible to it. Keying onBounds.X0,Y0,X1,Y1@Sharemakes the gate answer "is this a different container?" instead of "is there a container?", and that's the question that actually matters for whether the English needs re-centring. One interpolation, as promised~ ♪shareinclusion is defensible, not gratuitous. I traced it:ContainerFit.Shareis the fill's percent-of-page, and a tolerance change that fills further inside the same outline keeps the sameBoundingBoxbut drifts the share. Including it closes the gap completely rather than leaving a "well, technically…" corner. The doc comment at PageWorkspacePage.razor:727-733 says exactly this. Sharp~ResizeObserveris now airtight. caption.js:12-16 watches for dimension changes (zoom, window resize);CaptionSignaturewatches for identity changes (move, re-fill, text change). Neither does the other's job, neither leaves a gap. The comment at :698-699 already documented the intent — "Their SIZE changing is the script's own business" — and this PR makes the signature live up to its half of that contract.CaptionSignatureto the old existence-only form, rebuilt, and ranA_container_that_moves_without_resizing_re_centresagainst it: it failed (Assert.True() Failureat line 634, centring count stayed atsettled). Restored the fix: passed. That's not a tautology — it's a regression proof. ♡Filler.Fit=(0.15, 0.15, 0.55, 0.65)→ 0.40 × 0.50. New =(0.35, 0.25, 0.75, 0.75)→ 0.40 × 0.50. Same dimensions, moved across the page — precisely the case theResizeObserveris blind to. The PR body's "0.40×0.50 either way" checks out to the decimal.Typing_beside_the_captions_does_not_re_centre_them(:584) beat for beat:SeedWorld→ navigate to translation tab →WaitForAssertioninitial centring → capturesettledcount → mutate state → assert count moved. No new plumbing invented.No blockers. No non-blockers worth raising — the doc comment already explains the
sharereasoning, the signature string is comparison-only (never parsed, so the missing delimiter beforer.Target ?? r.Sourceis a non-issue), and the test count tracks (275 = 274 + 1 new). Fufu~ you even noted theResizeObserverbrowser-support 💡 correctly — Blazor Server's floor is far above Safari 13.1.Automated review by Jibril · 2026-07-30
CI/CD: absent for head
35d9153(PR just opened, no coverage bot yet) · Local checks: build 0 warnings / 0 errors, 275/275 BlazorAdapter tests pass, new test verified directional (fails on reverted code, passes on fix)