Synchronize native scroll state with the UI tree - #5
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughWin32 scroll handling now converts positions between native device pixels and tree layout units. Scroll-container documents with nonnegative node IDs remain vertically positioned at zero when scrollbars or scroll positions are updated. ChangesWin32 scroll synchronization
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to Framework scroll positions and native scrollbar positions are synchronized in their respective units while preserving Controls offsets. No concrete regression remains that should block merging. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
Problem
Win32 scroll widgets update their own scrollbar and document position, while framework layout keeps a separate scroll offset. After native wheel or scrollbar input, rendered content and the Core tree can disagree.
Change
Verification
Integration retest: the first image-based scroll check did not exercise JSX
onScroll. Manual interaction exposed that the compiler delegated this non-bubbling event tobody; compiler#1 binds it to the target. The rebuilt Windows app with all four changes appeared fixed in manual retest. Merge this PR with that compiler dependency in mind.Summary by CodeRabbit