Update search input height on narrow to be the same as in wide#88526
Update search input height on narrow to be the same as in wide#88526bernhardoj wants to merge 5 commits intoExpensify:mainfrom
Conversation
|
@aimane-chnaif 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] |
|
Change requested by @shawnborton to make the input height the same in narrow and wide version. |
|
cc @Expensify/design and specifically JDUB - after seeing this, dang, I wonder if it feels too short for mobile devices? |
|
Let's wait to merge until we get further confirmation from Design team. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 22ad9c3fe3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Updated to 44 |
|
🚧 @shawnborton has triggered a test Expensify/App build. You can view the workflow run here. |
This comment has been minimized.
This comment has been minimized.
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
|
Tested and that feels pretty solid to me! Again, let's have the Design homies weigh in but I think this could work well. |
|
That feels like a pretty solid size to me. Can we update the focused state so that the input doesn't jump in height though? CleanShot.2026-04-22.at.08.32.59.mp4 |
|
Oh that's a good shout, I would be a fan of that personally but that might be a bigger change since that touches the router? |
Oh right - I didn't think about that haha. Fine to not mess with it here if it's too much scope. |
|
It's easy to keep the height the same (44px) between the expanded and non-expanded state. web.mp4But do we want to update all the inputs' height to 44px? web.2.mp4 |
|
I think in the case of web, it would be ideal if the router had the same size input that we're using there. Basically the idea is to not have any size jumping on each platform. |
|
I'm good with that Shawn. Though it bothers me less on desktop since you see the whole router popover takeover thingy—feels less weird on desktop to me, but I'm still down with what you've suggested. |
|
I feel the exact same way 🤝 happy to solve mobile first and then follow up with web later. |
|
Updated |
|
🚧 @shawnborton 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! 🧪🧪
|
|
Nice, this feels great to me 👍 |
joekaufmanexpensify
left a comment
There was a problem hiding this comment.
Good for product
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppios.movios-landscape.moviOS: mWeb Safarimsafari.movMacOS: Chrome / Safari |
|
I am not seeing any visual change before and after this branch. Is this expected? ios.mov |
|
@aimane-chnaif try to inspect the element and see if the height is 44px |
| minimalTopBarOffset: -112, | ||
| minimalTopBarWithFiltersOffset: -156, | ||
| searchHeaderDefaultOffset: 0, | ||
| searchListContentMarginTop: 126, | ||
| searchListContentWithFiltersMarginTop: 170, | ||
| searchListContentMarginTop: 112, | ||
| searchListContentWithFiltersMarginTop: 156, |
There was a problem hiding this comment.
Why 14px difference here while height only reduced 8px?
There was a problem hiding this comment.
Nice catch. This was recalculated when using the 32px.
Yes, it's 20px difference, but there are actions bar with 40px height + 16px padding = 56px, and the previous height is 70px (52px + 2px (input border) + 16px)
There was a problem hiding this comment.
Just curious: why absolute position styling in the first implementation? If relative, no need to recalculate these values when input container height changes.
There was a problem hiding this comment.
I think to achieve this effect, where the top part shows when scrolling top.
mw.mp4
|
Code Review The changes look correct and well-scoped. A few observations: What's good:
Minor note:
No blocking issues found. |
|
@bernhardoj perf tests are failing |
|
Might be flaky. Can you please re-run that workflow? |
|
Codex Review: Didn't find any major issues. Keep it up! ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |




Explanation of Change
Fixed Issues
$ #84876
PROPOSAL:
Tests
Same as QA Steps
Offline tests
Same as QA Steps
QA Steps
For mobile screen only
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand 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: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
web.mp4