App
App copied to clipboard
[HOLD for payment 2024-12-17] [$125] mWeb - Copilot - User navigated to incorrect page when using device back button in MC page
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 9.0.66-0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Email or phone of affected tester (no customers): [email protected] Issue reported by: Applause - Internal Team
Action Performed:
- Open the staging.new.expensify.com website
- Tap on "Settings" on the bottom of the screen
- Tap on "Security" and select "Add Copilot"
- Select any user as copilot
- Select an access level
- Tap on "Add Copilot"
- On Magic Code page, use the device back button to return to previous page
- Verify you are redirected to copilot confirmation page
Expected Result:
When using the device back button to return to previous page on magic code page while adding copilot, the user should land on the copilot confirmation page
Actual Result:
User lands on "Access Level" page instead of copilot confirmation, when using the device back button while in the Magic Code page
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android: Standalone
- [ ] Android: HybridApp
- [x] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [ ] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/user-attachments/assets/a0e22933-33e7-4135-92ac-f3345841c0a0
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021861786354506701472
- Upwork Job ID: 1861786354506701472
- Last Price Increase: 2024-11-27
- Automatic offers:
- dominictb | Reviewer | 105157484
- daledah | Contributor | 105157485
Issue Owner
Current Issue Owner: @twisterdotcom
Triggered auto assignment to @twisterdotcom (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Edited by proposal-police: This proposal was edited at 2024-11-26 11:01:06 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
User lands on "Access Level" page instead of copilot confirmation, when using the device back button while in the Magic Code page
What is the root cause of that problem?
- The MC page is just a modal:
https://github.com/Expensify/App/blob/0135d4ee1f803622a9ceea894fde62791ceed775/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx#L79
so when pressing on back button, the navigate user to the Access Level page.
What changes do you think we should make in order to solve the problem?
- We should user the modal: https://github.com/Expensify/App/blob/0135d4ee1f803622a9ceea894fde62791ceed775/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx#L79 as:
<DelegateMagicCodeModal shouldHandleNavigationBack ... /> // can use shouldHandleNavigationBack={Browser.isMobileChrome()}
- The
shouldHandleNavigationBackwill be passed down to Modal component:
https://github.com/Expensify/App/blob/0135d4ee1f803622a9ceea894fde62791ceed775/src/components/Modal/index.tsx#L10
and is used in:
https://github.com/Expensify/App/blob/0135d4ee1f803622a9ceea894fde62791ceed775/src/components/Modal/index.tsx#L50-L53
With this, pressing back button will navigate user to the correct page.
What alternative solutions did you explore? (Optional)
Web:
https://github.com/user-attachments/assets/c6a22c6f-34b5-481a-8ef8-31f2f527110b
iOS:
https://github.com/user-attachments/assets/5cb0fbdf-6804-4fa6-8260-27a41c42e12d
Android mWeb Chrome:
https://github.com/user-attachments/assets/c7084fc9-b9d6-45aa-8573-4622db6d09cf
I cannot recreate.
@twisterdotcom I can replicate this bug on the web (by using the browser back button in case MacOS chrome and device back button in case android chrome). In your video, it seems you used the back button within the app, but the OP specified that the device's back button should be used:
https://github.com/user-attachments/assets/2ffab2a5-cf01-4b75-9ced-682e6a4c4f6b
https://github.com/user-attachments/assets/6d9f66b9-ab69-4f09-92cb-97512a7e4214
Ah, my android device doesn't have a back button, I guess I would need to enable it in the settings. Okay, browser made it much easier. I agree then, this is a bug. Niche though.
Job added to Upwork: https://www.upwork.com/jobs/~021861786354506701472
Triggered auto assignment to Contributor-plus team member for initial proposal review - @dominictb (External)
Upwork job price has been updated to $125
Proposal
Please re-state the problem that we are trying to solve in this issue
When using the device back button while in the Magic Code page, user lands on "Access Level" page instead of copilot confirmation page.
What is the root cause of that problem?
The RC of the problem is that the copilot confirmation page (ConfirmDelegatePage) contains a modal component DelegateMagicCodeModal which becomes visible when we tap the Add copilot button while the page under the visible modal is the copilot confirmation page (ConfirmDelegatePage).
Our issue occurs because the DelegateMagicCodeModal does not currently include logic that handles hardware / browser back button in order to return to the copilot confirmation page when going back from the modal.
[!caution] This issue is present on all platforms where hardware / browser back button is available - this includes Web / Android: mWeb Chrome / iOS: mWeb Safari.
Here's the proof
| Web: Chrome | iOS: mWeb Safari | Android: mWeb Chrome |
|---|---|---|
What changes do you think we should make in order to solve the problem?
[!note]
- The reason I decided to post a proposal is because the other proposal would only solve the issue on mWeb Chrome which I don't consider a complete solution.
- Another error of the other proposal is that
DelegateMagicCodeModaldoes not take theshouldHandleNavigationBackprop dirrectly.
In the ValidateCodeActionModal component, pass shouldHandleNavigationBack (true) without any condition, which would ensure we have the same behaviour of the hardware / browser back button on all platforms where this issue is present, as per the Expected result.
Result videos
| Web: Chrome | iOS: mWeb Safari | Android: mWeb Chrome |
|---|---|---|
Just a note for reviewer:
- In proposal, I already posted two options in code change:
<DelegateMagicCodeModal shouldHandleNavigationBack ... /> // can use shouldHandleNavigationBack={Browser.isMobileChrome()}
Use Browser.isMobileChrome() if we only want to fix it in mobile chrome.
- In proposal, I mentioned:
The shouldHandleNavigationBack will be passed down to Modal component:
This is simply a case of prop drilling and doesnβt require detailed explanation in the proposal. It should be addressed directly in the PR.
@ikevin127 Thanks for your proposal but I don't think there're any significant differences between yours and the other. All the minor details can be worked out in implementation phase.
@daledah proposal here LGTM.
C+ Reviewed πππ
Triggered auto assignment to @MarioExpensify, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
Nice!! Thank you @dominictb, let's move forward with @daledah proposal.
π£ @dominictb π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @daledah π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
Use
Browser.isMobileChrome()if we only want to fix it in mobile chrome.
@daledah I don't think that is the intention, we should have this fixed in native with back buttons as well, @twisterdotcom please correct me if I got this wrong.
Sounds good.
Reviewing label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.73-8 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53438
If no regressions arise, payment will be issued on 2024-12-17. :confetti_ball:
For reference, here are some details about the assignees on this issue:
- @dominictb requires payment automatic offer (Reviewer)
- @daledah requires payment automatic offer (Contributor)
@dominictb @twisterdotcom @dominictb The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
Payment Summary:
BugZero Checklist:
- [x] [Contributor] Classify the bug:
Bug classification
Source of bug:
- [ ] 1a. Result of the original design (eg. a case wasn't considered)
- [x] 1b. Mistake during implementation
- [ ] 1c. Backend bug
- [ ] 1z. Other:
Where bug was reported:
- [x] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
- [ ] 2b. Reported on staging (eg. found during regression or PR testing)
- [ ] 2d. Reported on a PR
- [ ] 2z. Other:
Who reported the bug:
- [ ] 3a. Expensify user
- [ ] 3b. Expensify employee
- [ ] 3c. Contributor
- [x] 3d. QA
- [ ] 3z. Other:
-
[x] [Contributor] 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: https://github.com/Expensify/App/pull/49445/files#r1889759874
-
[x] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: NA
-
[x] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
-
[x] [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Test:
- Open Settings > Security > Add copilot
- Proceed adding copilot until the magic code step
- On magic code page, press the device's or browser's back button
- Verify that user is redirected to copilot confirmation page
Do we agree π or π
Waiting on @dominictb to accept the Upwork offer now.
@twisterdotcom @dominictb @daledah @MarioExpensify this issue is now 4 weeks old, please consider:
- Finding a contributor to fix the bug
- Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
- If you have any questions, don't hesitate to start a discussion in #expensify-open-source
Thanks!
@twisterdotcom, @dominictb, @daledah, @MarioExpensify Eep! 4 days overdue now. Issues have feelings too...
Waiting on @dominictb to accept the Upwork offer now.
@twisterdotcom This is done, thanks.
@twisterdotcom, @dominictb, @daledah, @MarioExpensify Huh... This is 4 days overdue. Who can take care of this?
I think this can be closed now, but I'll wait @twisterdotcom to be back Edit: Moving this to Weekly just to clear up my dashboard