chore: on-device isolation flags for the #610 iOS nav repaint (diagnostic)#637
Merged
Conversation
…aint
Five header-CSS attempts failed and the GPU compositor promotion made no
on-device difference, which rules out the sticky element's own layer. The new
back-swipe-blank symptom (iOS only, both WebKit browsers) points the whole
class of bug at the client router's paint/snapshot timing, not the header.
Add temporary, guarded diagnostic levers (default OFF, so the production nav
path is unchanged) so one on-device round isolates the cause instead of
another blind guess:
- window.__webjsDiag.raf: wait a requestAnimationFrame before the forward
swap AND the popstate (back) swap, so WebKit paints at a frame boundary
(the timing Turbo uses; webjs currently swaps synchronously).
- window.__webjsDiag.scrollfirst: scroll-to-top BEFORE the forward swap, so
a preserved sticky header never sees a content height change while stuck.
- blog `?h=static`: drop position:sticky to tell sticky-recalc from a
page-level repaint.
The blog reads `?raf` / `?scrollfirst` into window.__webjsDiag on load (the
flag is lost from the URL on the soft nav itself, so it is captured once) and
`?h=static` server-side onto the preserved header. All temporary; removed
once the root fix lands. Doc gate bypassed (internal, undocumented, temporary).
Re #610.
Claude-Session: https://claude.ai/code/session_01W8RLiSnkwKXDmnkoasQfZF
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.
Why a diagnostic, not another fix
Five header-CSS attempts failed, and the GPU compositor promotion (#636) made no on-device difference (both
/and/?nofixflashed), which rules out the sticky element's own compositing layer. The new symptom (back-swipe shows a blank page, iOS only, both WebKit browsers) cannot be a header-CSS issue at all. It points the whole class of bug at the client router's paint/snapshot timing.Rather than a sixth blind guess, this ships temporary, guarded levers (default OFF, production path unchanged) so one on-device round isolates the cause.
The levers
?raf=1: the router waits arequestAnimationFramebefore the forward swap AND the popstate (back) swap, so WebKit paints at a frame boundary. webjs currently swaps synchronously, whereas Turbo waits a rAF (the single biggest router difference).?scrollfirst=1: scroll-to-top happens BEFORE the forward swap, so a preserved sticky header never sees a content-height change while stuck.?h=static: dropsposition: sticky, to tell a sticky-recalc apart from a page-level repaint.Flags combine (
?raf=1&scrollfirst=1). All guarded behindwindow.__webjsDiag; removed once the root fix lands.Verification
Blog SSR 200 across
/,/?h=static,/?raf=1&scrollfirst=1; router unit tests 150/150;webjs checkclean. Default behavior is byte-identical with the flags off.Re #610.
https://claude.ai/code/session_01W8RLiSnkwKXDmnkoasQfZF