fix(html): ink lands where the finger went under a fit the rects leave out - #918
Merged
Merged
Conversation
…e out The ink tool mapped a pointer through a page's own rect. Every other input to that mapping is a rect, and a webkit view leaves the fit's zoom out of a rect while a pointer carries it, so the stroke landed as far out as the page is scaled - about twice, on a phone. A pointer now comes back through `odr.getViewportRect` before the page is picked and the point is mapped. Chromium reports both alike and was never affected, so the new browser check stands in a rect of its own to reach the case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XASU9ZfSJ6QwsAJGE3DrN1
andiwand
force-pushed
the
fix-ink-under-a-fit-the-rects-leave-out
branch
from
September 20, 2026 17:28
6a52189 to
5385c89
Compare
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.
Drawing on a pdf put the stroke about twice as far from the page's corner as
the finger went.
OpenDocument.ioshits it on every phone;OpenDocument.droidnever did.
toBoxmapped a pointer throughpage.getBoundingClientRect(). Every otherinput to it is a rect — the glyph and run boxes the text marks are built from —
so the raw layout box is the space it is written against, and those cancel. A
pointer is the one input that does not arrive in it.
Measured in the app, on an iPhone 17 simulator:
So the scale came out 0.999 where it should be 0.487, from an origin of 16.0
where the page is drawn at 7.8.
layoutScalenow brings a pointer back into the rects' space beforepageAtand
toBoxsee it.pageAtneeds it too: it takes rects frompushBoxandpointers from
onPointerDown, so with the spaces mixed a page far down thelist is picked wrong. It is read once per event, not per coalesced sample —
each read costs two layouts. Without
viewport.jsthe scale is 1 and nothingchanges.
Chromium fits the page in the view itself, so odr's zoom stays 1,
rectFactor()is 1 and both rects agree. A webkit view does no such fit.
Checks
The browser suite cannot reach the case on its own, so the new check stands in
a
getViewportRectthat halves the box.[45.1, 746.9]instead of
[100, 692]🤖 Generated with Claude Code
https://claude.ai/code/session_01XASU9ZfSJ6QwsAJGE3DrN1