Prevent layout shift caused by the AddressSearch dropdown

[luacmartins]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. On NewDot, navigate to /bank-account/company
2. In the address field, start typing an address.
3. Notice that as the dropdown shows up, it shifts the entire form down.

layoutshift.mov

Expected Result:

The form shouldn't shift.

Actual Result:

The form shifts.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround? Yes, layout only.

Platform:

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number:
Reproducible in staging?:
Reproducible in production?:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:

View all open jobs on GitHub

[luacmartins]

@Expensify/design is this something we should fix?

[shawnborton]

Agree, the dropdown should be absolutely positioned on top of the other elements. Maybe we should even give it a bit of a shadow too to create some more visual separation as well.

[luacmartins]

Thanks for confirming @shawnborton! I'm coming across an edge case when:

1. The dropdown is too close to the bottom of the screen
   

2. The input is inside a nested form.
   

The library we are using does not expose a way to limit the maximum number of results (so we always display 5 if there are enough matches). One suggestion that I have is to display the dropdown show above the input in those cases. Any thoughts here?

[shawnborton]

Displaying above is interesting - how might that look on mobile? Are we able to get the text input to be focused and scrolled directly above the keyboard so that there is ample room for the results?

[luacmartins]

Hmm my suggestion might have issues with shorter forms. If the form is short there isn't enough room for the dropdown above the input and we can't scroll, so the view is either cut at the bottom or at the top. Here's an example:

Now I'm not too sure how to solve this one. Any ideas @shawnborton?

[shawnborton]

Hmm the only thing I can think of is to always launch the form to the bottom of the input and try to scroll the input towards the top of the viewport as much as possible.

[luacmartins]

Still not sure how to approach the edge cases here. I'm gonna try to come back to this one next week.

[luacmartins]

Haven't made any progress here yet. I will try to look into it next week.

[parasharrajat]

I have a suggestion. 🐿️ 🤡

The issue with the approach we are exploring so far.

• This just doesn't work for mobile.
• This will not fit the mobile web (we don't know the resolution of the device). This becomes worse when the keyboard is Open.
• There would be positioning challenges.

I think we should create a new screen for selecting the address and show the Address selector as it is on that screen.

1. Show a read-only input in this form whose UI does not change.
2. When a user clicks it, Open the new page with a single input on the top where the user can select the address and press enter.
3. On Press of entering, he would come back to this screen and that read-only input would be filled with selected address.

[shawnborton]

I like that idea, it reminds me of how Google Maps handles adding in addresses for directions.

[luacmartins]

Sounds like a good idea! I'll do some more thinking on how to handle the manual address input solution we are implementing.

[luacmartins]

I will try to carve out some time to work on this issue this week!

[luacmartins]

I actually discussed this 1:1 with @marcaaron. Since nothing is broken and the solution at hand is really involved and hard to maintain, we will just close this for now.