Report field - Multiline input for name field in report field does not scroll#77324
Report field - Multiline input for name field in report field does not scroll#77324Julesssss merged 15 commits intoExpensify:mainfrom
Conversation
|
Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers! |
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
|
@mohammadjafarinejad Which issue made you change the solution? |
|
@huult On Safari, the bug persists even when visible and hidden inputs have the same width. Please check the comment in forceSafariTextReflow. |
|
It looks like a hack to me. |
|
I disabled REC-20251217101812.mp4
I'll try to find a better solution. I'd appreciate any ideas you might have. |
|
@mohammadjafarinejad I think we should identify the RCA first. If we can’t do that, we should reopen this for proposals. |
|
Okay, I'll update here once I found the root cause and a correct solution. |
|
@mohammadjafarinejad Do you have any updates? |
|
@mohammadjafarinejad bump |
@huult Sorry for the delay. Yes, I found a better solution. I’ll try to update today with the correct solution. |
| (height: number) => { | ||
| setTextInputHeight(height); | ||
|
|
||
| // Safari-specific: Force text layout recalculation when height changes |
There was a problem hiding this comment.
We should avoid platform specific logic like this.
There was a problem hiding this comment.
If this is still necessary, ideally it would be extracted to a web-component. Then that component could handle the browser specific logic
|
Hey @Julesssss @huult Root Cause AnalysisOur auto-grow implementation works like this:
The Bug: When you delete characters and the number of lines should decrease (e.g., 2 lines → 1 line):
Why? Safari sees the TextInput still has the same Result: Text stays visually stuck on the old number of lines.
Potential SolutionsSolution 1: Use
|
Without text-wrap: balance |
With text-wrap: balance |
|---|---|
![]() |
![]() |
Downside: Changes text wrapping behavior (distributes words differently across lines).
Solution 2: Force reflow via style manipulation
On Safari, whenever height changes, force line wrapping recalculation by toggling a CSS property, example:
// Force text reflow by temporarily changing wrapping behavior
if ((isSafari() || isMobileSafari()) && height !== textInputHeight && input.current) {
const element = input.current;
const originalWhiteSpace = element.style.whiteSpace;
element.style.whiteSpace = 'nowrap';
// Force synchronous layout calculation
void element.offsetHeight; // or element.getBoundingClientRect();
element.style.whiteSpace = originalWhiteSpace || '';
}Solution 3: Accept scrollbar flash on Safari
Remove height + overflow: hidden on Safari only, use maxHeight + overflow: auto instead.
Downside: Brief scrollbar flash when adding new lines, but text always reflows correctly.
Question: Which solution/tradeoff should we go with?
|
Thanks for sharing details. I think 2 is best solution here. To confirm though, we can do this with just a style prop change? If so lets go ahead. |
|
@huult Ready for re-review. New Screenshots/VideosiOS: mWeb Safari2_ios_safari.mp4MacOS: Chrome / Safari2_safari.mp43_IOS.mp43_SAFARI.mp4 |
| {!!contentWidth && isPrefixCharacterPaddingCalculated && ( | ||
| <View | ||
| style={[inputStyle as ViewStyle, styles.hiddenElementOutsideOfWindow, styles.visibilityHidden, styles.wAuto, inputPaddingLeft]} | ||
| style={[inputStyle as ViewStyle, styles.hiddenElementOutsideOfWindow, styles.visibilityHidden, styles.wAuto, hiddenInputStyle as ViewStyle, inputPaddingLeft]} |
There was a problem hiding this comment.
Why do we need hiddenInputStyle here?
There was a problem hiding this comment.
You're right, prefix inputs are single-line and don't need this fix.
| onSetTextInputWidth, | ||
| onSetTextInputHeight, | ||
| isPrefixCharacterPaddingCalculated, | ||
| hiddenInputStyle, |
There was a problem hiding this comment.
Is there any reason we need to introduce a new prop for the TextInputMeasurement component? I see that the native and web versions use the same style.
There was a problem hiding this comment.
Thanks, updated.
Screen.Recording.2025-12-26.at.11.26.22.mov@mohammadjafarinejad This issue was caused by this PR. Could you please double-check the code? BaseTextInput is used in many places, so after updating it, please verify that the existing usages are still working correctly. |
|
Added new videos (#77324 (comment)). @huult Ready for re-review. |
| element.style.whiteSpace = 'nowrap'; | ||
| // Force synchronous layout calculation | ||
| // eslint-disable-next-line no-void | ||
| void element.offsetHeight; |
There was a problem hiding this comment.
| void element.offsetHeight; | |
| requestAnimationFrame(() => { | |
| element.style.whiteSpace = originalWhiteSpace || ''; | |
| }); |
@mohammadjafarinejad What do you think about using requestAnimationFrame here instead of reading offsetHeight? It can improve performance by avoiding synchronous reflow, especially if textInputHeight changes frequently during typing.
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppScreen.Recording.2025-12-30.at.10.17.36.mp4Android: mWeb ChromeScreen.Recording.2025-12-30.at.10.18.54.mp4iOS: HybridAppScreen.Recording.2025-12-30.at.10.21.56.mp4iOS: mWeb SafariScreen.Recording.2025-12-30.at.10.23.17.mp4MacOS: Chrome / SafariScreen.Recording.2025-12-30.at.10.11.25.mp4 |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/Julesssss in version: 9.2.94-0 🚀
|
Report field - Multiline input for name field in report field does not scroll
|
🚀 Deployed to production by https://github.com/arosiclair in version: 9.2.94-4 🚀
|



Explanation of Change
Report field - Multiline input for name field in report field does not scroll
Fixed Issues
$ #76785
PROPOSAL: #76785 (comment)
Tests
A scroll is displayed to show all the input by scrolling down, OR
The user can view the far right by navigating right
Verify that no errors appear in the JS console
Offline tests
Same as tests.
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
ANDROID.mp4
Android: mWeb Chrome
ANDROID_WEB.mp4
iOS: Native
IOS.mp4
iOS: mWeb Safari
IOS_WEB.mp4
MacOS: Chrome / Safari
WEB.mp4