Make editable cell hover target full height - #96318
Conversation
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
|
@nyomanjyotisa Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
@nyomanjyotisa I’m testing it now and will let you know once I’m done. Thanks. |
|
@nyomanjyotisa It’s ready for review. Thanks! |
|
@shawnborton, @dubielzyk-expensify could you please share you thoughts. thanks. |
|
🚧 dubielzyk-expensify has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
This is working well for me. Curious to see what @Expensify/design thinks. A violation expense has some un-interactable area, but I think that's expected |
|
Feels good to me too 👍 |
|
@nyomanjyotisa, Gentle bump. thanks. |
|
@nyomanjyotisa it's been 5 days since a review which is unacceptable, please prioritize this PR. Thx. |
nyomanjyotisa
left a comment
There was a problem hiding this comment.
The behavior looks correct in testing. I found one small styling-guideline issue before completing the reviewer checklist.
| justifyContent: 'center', | ||
| }, | ||
|
|
||
| editableCellFullHeightHoverTarget: { |
There was a problem hiding this comment.
Per STYLING.md, single-use styles should use existing helpers. Both editableCellFullHeightHoverTarget and transactionItemRowWide are used once and can be replaced with [styles.flex1, styles.w100, styles.justifyContentCenter] and styles.alignSelfStretch, respectively. Could we remove those two styles? editableCellColumn is used across six columns, so keeping that shared style makes sense.
There was a problem hiding this comment.
Thanks, addressed. I removed the two single-use styles and replaced them with the existing style helpers, while keeping the shared editableCellColumn style.
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid-pr96318.mp4Android: mWeb ChromeAndroid-mWeb-pr96318.mp4iOS: HybridAppios-pr96318.mp4iOS: mWeb Safariios-mWeb-pr96318.mp4MacOS: Chrome / SafariChrome-pr96318.mp4Safari-pr96318.mp4 |
|
@MonilBhavsar, I'm doing another round of testing. Could you please hold off on merging this for now? Thanks! |
MonilBhavsar
left a comment
There was a problem hiding this comment.
Okay, feel free to request a review once done
|
@nyomanjyotisa I found and fixed a regression affecting rows with validation messages, such as “Missing category.” Before: Screencast.From.2026-07-24.14-31-21.mp4After: Screencast.From.2026-07-24.12-45-36.fi.mp4 |
|
@nyomanjyotisa, could you please take another look, when you get a chance. thanks. |
nyomanjyotisa
left a comment
There was a problem hiding this comment.
The latest validation-row fix works in the regular Spend/report tables, and the focused tests pass. I found two layout regressions in related paths; please address the inline comments.
| columns={columns} | ||
| isDisabled={isPendingDelete} | ||
| style={!shouldUseNarrowLayout ? [styles.p3, styles.pv2, styles.noBorderRadius] : [styles.p4, styles.noBorderRadius]} | ||
| style={!shouldUseNarrowLayout ? [styles.ph3, styles.noBorderRadius] : [styles.p4, styles.noBorderRadius]} |
There was a problem hiding this comment.
At medium widths, line 247 renders the narrow row while this condition remains false. This removes its vertical padding: a clean row drops from 56px to 40px, and a validation row from 84px to 68px. Could we preserve the previous padding when the effective row layout is narrow?
| testID="transaction-item-row" | ||
| > | ||
| <View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.gap3]}> | ||
| <View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.gap3, styles.tableRowHeight]}> |
There was a problem hiding this comment.
This min-height affects every wide TransactionItemRow, but SearchStaticList and TransactionGroupListExpanded still add styles.pv2. I reproduced expanded-group rows at 72px—or 94px with a validation message—versus 56px/78px in the regular table. Could we preserve the existing row heights in the remaining callers?
MonilBhavsar
left a comment
There was a problem hiding this comment.
Awaiting feedback from author
…tTransactionItemBody
|
@nyomanjyotisa Thanks, I addressed both layout regressions:
Could you please take another look when you get a chance? |
Explanation of Change
This follow-up updates editable table cells so the hover target covers the full row height while keeping the visual layout unchanged.
The editable cell now extends into the row’s vertical padding area, with matching inner padding so the content remains visually aligned.
Fixed Issues
$ #93242
PROPOSAL: #93242 (comment)
Tests
Offline tests
Same as tests.
QA Steps
Same as tests.
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, 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.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
Screen.Recording.2026-07-17.at.6.14.38.PM.mov
Android: mWeb Chrome
Screen_Recording_20260717_182625_Chrome.mp4
iOS: Native
Screen.Recording.2026-07-17.at.6.32.19.PM.mov
iOS: mWeb Safari
Screen.Recording.2026-07-17.at.6.36.26.PM.mov
MacOS: Chrome / Safari
Screencast.From.2026-07-18.09-55-27.mp4