[relextm19]

Summary

Closes #169

Add onScroll event to EnrichedTextInput triggered when the content is scrolled. Payload is the same as in the React Native implementation

nativeEvent:{
  contentOffset: {
      x: number;
      y: number;
    };
}

Test Plan

Check the metro logs when running the mobile example or browser logs when running the web test. You can also write your own handler for onScroll and test it yourself

Screenshots / Videos

Compatibility

OS	Implemented
iOS	✅
Android	✅
Web	✅

Checklist

• E2E tests are passing
• Required E2E tests have been added (if applicable)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Copilot]

🟡 Changes recommended

The new fullscreen row invalidates existing screenshot baselines, and scroll events have cross-platform throttling, unit, and precision errors.

6 open issues

• Regenerate fullscreen screenshot baselines after layout changes · New
• Use inclusive scroll throttle interval comparisons · New
• Convert native scroll pixels to density-independent coordinates · New
• Preserve fractional scroll coordinates in native event payloads · New
• Treat zero scroll throttle as no throttling on web · New
• Emit the latest scroll offset with trailing throttle delivery · New

_{Review effort: Balanced}

[exploIF]

I think we should use similar approach to what we are doing for onChangeHtml. If handler is not set up we should avoid any calculations. See how isOnChangeTextSet is implemented

[szydlovsky]

Did a checkup over the layoutSubviews change that bugged me and it looks legit!

[exploIF]

Code-wise looks good, asked @szydlovsky to do a final testing check 🙌

[szydlovsky]

@relextm19 actually, I'm seeing some strange Android value jumps from the onScroll, specifically when we're still within the maxHeight (so theoretically input should have no scroll offset) and adding some new lines.

Screen.Recording.2026-11-12.at.18.28.38.mov

Having said that, I think it might be rather an issue of our jumps on layout when adding new lines, rather than the actual offset calculation. The issue is probably unrelated to this PR but I'll do some digging and check what happens on the current main. Maybe we can just block event's emitting as long as the layout process is running?