[HOLD for payment 2024-03-13] [$1000] Android - Personal Details - User can open both Address and Date of birth when quick tap on them

[lanitochka17]

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

---

Version Number: 1.4.10-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. Open staging.new.expensify.com
2. Navigate to Settings> Profile > Personal details
3. Tap on Address field and than quickly tap Date of birth

Expected Result:

User should navigate to Address screen when tap on Address field

Actual Result:

User navigates to Address screen and than land on Date of birth screen

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6306297_1702069686347.az_recorder_20231208_182128.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01cc50fcdb96ee2879
• Upwork Job ID: 1733233936302374912
• Last Price Increase: 2024-02-21

[melvin-bot]

Triggered auto assignment to @adelekennedy (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01cc50fcdb96ee2879

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @c3024 (External)

[gijoe0295]

Proposal

Please re-state the problem that we are trying to solve in this issue.

User can open both Address and Date of birth when quick tap on them

What is the root cause of that problem?

We do not restrict a single action at a time. That's why even while an action is executing, another action can push to the queue.

What changes do you think we should make in order to solve the problem?

We can apply the useWaitForNavigation - isExecuting - singleExecution approach that we have been using across the app to make sure it only allow a single execution at a time. For example here.

For example:

onPress={() => singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_LEGAL_NAME)))}

What alternative solutions did you explore? (Optional)

Check for other places using MenuItem because it may have the same issue.

[neonbhai]

Proposal

Please re-state the problem that we are trying to solve in this issue.

User can open both Address and Date of birth when quick tap on them

What is the root cause of that problem?

Logic to prevent quick tap in this Menu Item is missing on the PersonalDetailsInitialPage.

What changes do you think we should make in order to solve the problem?

We will use the useSingleExecution hook when navigation on this page.

const {singleExecution, isExecuting} = useSingleExecution();

This will be coupled with

const waitForNavigate = useWaitForNavigation();

Then replace:

• App/src/pages/settings/Profile/PersonalDetails/PersonalDetailsInitialPage.js

  Line 84 in adbeba1

  onPress={() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_LEGAL_NAME)}

  with

  onPress={singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_LEGAL_NAME)))}

• App/src/pages/settings/Profile/PersonalDetails/PersonalDetailsInitialPage.js

  Line 90 in adbeba1

  onPress={() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_DATE_OF_BIRTH)}

  with

  onPress={singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_DATE_OF_BIRTH)))}

• App/src/pages/settings/Profile/PersonalDetails/PersonalDetailsInitialPage.js

  Line 97 in adbeba1

  onPress={() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_ADDRESS)}

  with

  onPress={singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.SETTINGS_PERSONAL_DETAILS_ADDRESS)))}

[tienifr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

User navigates to Address screen and than land on Date of birth screen

What is the root cause of that problem?

This is happening with almost all the MenuItem navigates to another page. This is because the user clicks on the second menu item before the first menu item finishes navigating.

What changes do you think we should make in order to solve the problem?

We used to fix this in another place using a combination of singleExecution and waitForNavigate as can be seen here.

But this is happening with all MenuItem so I think we should come up with a global fix to avoid this occurring again. Here's my suggestions:

1. Create a MenuItemGroup component which will use the useSingleExecution and provide a singleExecution method to its children via a context
2. Wrap the MenuItems or MenuItemWithTopDescriptions inside a screen (where we want to fix) in 1 MenuItemGroup
3. Update the MenuItem component to get singleExecution from context (from the MenuItemGroup passed down). If singleExecution exists, then wrap its onPress call inside it (and inside waitForNavigate)
4. So any time we create a new group of MenuItem, we'll wrap them inside MenuItemGroup, then it will have double tap prevention logic baked in and won't ever have this issue.

What alternative solutions did you explore? (Optional)

In step 3, if we don't want to add waitForNavigate there, we can add it to the MenuItem or MenuItemWithTopDescription individually when we use it.

Instead of using a Context, we can iterate the children and add singleExecution to the children, but I prefer Context since it will work well for any level of nested MenuItem inside other components.

[c3024]

@tienifr

Do we have any examples of Context used like this?

I see we have a MenuItemList component with iterative approach for MenuItems.

I think we like to selectively use the singleExecution for certain MenuItems and MenuItemsWithTopDescription only so I don't think we want to keep the Context at a top level so that deeply nested components get the value. If we use singleExecution for certain items only then we want to wrap only those items with provider. While Context can be beneficial in some cases where we can wrap many items, I don't see how it is beneficial than moving the logic to MenuItem and using a prop flag.

[tienifr]

Do we have any examples of Context used like this?

@c3024 we are frequently using Context when we need to pass a function/ref down to nested components, for example the ActionListContext

moving the logic to MenuItem and using a prop flag.

The key to using singleExecution is all the MenuItems need to share 1 single singleExecution, so there always have to be a wrapper around MenuItem that will provide the singleExecution, the MenuItemList is also 1 such wrapper. So I'm not sure what you mean by moving the logic to MenuItem and using a prop flag since MenuItem cannot contain all the logic by itself.

I think we like to selectively use the singleExecution for certain MenuItems and MenuItemsWithTopDescription only so I don't think we want to keep the Context at a top level so that deeply nested components get the value

The Context can be used along side the prop flag if we want to selectively use it. So we should understand the context approach as the same as what we're already doing in MenuItemList, just that now it can be used with any structure of nested MenuItems, MenuItemsWithTopDescriptions rather than just a simple list of MenuItem.

Instead of using a Context, we can iterate the children and add singleExecution to the children

Context is not required for this to work, but I think it's the cleanest approach and it abstracts the complexity away from the components that are using MenuItems

[c3024]

Thanks for the explanation.

Is there any case where we have two different components (with MenuItems or MenuItemWithTopDescriptions) rendered at the same time on screen?

[gijoe0295]

Is there any case where we have two different components (with MenuItems or MenuItemWithTopDescriptions) rendered at the same time on screen?

@c3024 There're a lot of. You can checkout the TaskView or ProfilePage... components. And what about the cases of MenuItem wrapped inside other components like OfflineWithFeedback? I think that approach may affect scalability. Also this issue does not happen to all MenuItems, just several. We can selectively use singleExecution for each of those. Safe and clean.

I think for these simple issues we should avoid over-engineering if there're simpler ways to do it. We already have so many hooks and contexts now.

[tienifr]

Is there any case where we have two different components (with MenuItems or MenuItemWithTopDescriptions) rendered at the same time on screen?

@c3024 There's this one and this one and a few others.

And what about the cases of MenuItem wrapped inside other components like OfflineWithFeedback?

Yeah this is exactly why using a MenuItemGroup as I mentioned is the best approach 😄

[c3024]

@tienifr

Would you mind sharing a test branch with changes you would do for any simple sample component in the repo?

[adelekennedy]

not overdue - testing proposals

[tienifr]

Working on it. Posting code change today.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@adelekennedy, @c3024 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[tienifr]

@c3024 Here's the test branch.

[melvin-bot]

@adelekennedy, @c3024 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[adelekennedy]

not overdue - test branch above

[tienifr]

Extended PR is ready for review #37164.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.47-10 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: User navigates to many pages when quickly press them in ProfilePage #37164

If no regressions arise, payment will be issued on 2024-03-13. 🎊

For reference, here are some details about the assignees on this issue:

• @c3024 requires payment (Needs manual offer from BZ)
• @tienifr requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@c3024] The PR that introduced the bug has been identified. Link to the PR:
• [@c3024] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@c3024] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@c3024] Determine if we should create a regression test for this bug.
• [@c3024] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@adelekennedy] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

Payment Summary

Upwork Job

• ROLE: @c3024 paid $(AMOUNT) via Upwork (LINK)
• ROLE: @tienifr paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@adelekennedy )

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1733233936302374912/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[adelekennedy]

This job closed so I re-used the posting - @c3024 & @tienifr will you apply here: https://www.upwork.com/jobs/~01d9acddb96214da33

[tienifr]

This job closed so I re-used the posting - @c3024 & @tienifr will you apply here: https://www.upwork.com/jobs/~01d9acddb96214da33

@adelekennedy I applied, thanks!

[adelekennedy]

@c3024 have you applied as well?

[c3024]

Yes @adelekennedy Applied. Thanks.

[adelekennedy]

hmm I hired you both on Monday but it didn't seem to go through - I've just done it again in Upwork 🤞

[tienifr]

@adelekennedy I’ve accepted the offer, thanks!

[c3024]

I've accepted too @adelekennedy

[adelekennedy]

Done! Thank you both for bearing with me