[HOLD for payment 2023-12-08] [$1000] Web - App does not display working report on back from 'something is wrong page'

[kbecciv]

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. Open the app
2. Open any report, to trigger something is wrong page, send any attachment, click on attachment and copy URL, send URL, delete the attachment and click on URL
3. Click on browser back, observe that it changes URL but it still displays something is wrong page
4. Reload and observe that app now displays proper report

Expected Result:

App should display chat report on back from 'something is wrong' page if report don't have any issue

Actual Result:

App still displays 'something is wrong' page on browser back click even though app changes URL to a working report

Workaround:

Unknown

Platforms:

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

• [ ] Android / native
• [ ] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [ ] MacOS / Desktop

Version Number: 1.3.41-2 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 Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/93399543/caf339c1-633f-4bf8-b4b7-db3968a9dba3

https://github.com/Expensify/App/assets/93399543/8a738523-b893-429d-ac72-e37547cd53ba

Expensify/Expensify Issue URL: Issue reported by: @dhanashree-sawant Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1689531247187909

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01f4efb0d0e28187e6
• Upwork Job ID: 1682055964789444608
• Last Price Increase: 2023-11-20
• Automatic offers:
• 0xmiroslav | Reviewer | 27774673
• WikusKriek | Contributor | 27774676
• dhanashree-sawant | Reporter | 27774677

[kameshwarnayak]

@0xmiroslav - Yes.

I believe this is the actual bug that is mentioned in the initial bug description. You can recreate it without attachment as demonstrated in this comment https://github.com/Expensify/App/issues/23068#issuecomment-1660007287

https://github.com/Expensify/App/issues/23068#issuecomment-1646582365 fixes 7. App redirects to not accessible chat (BUG2)

[parasharrajat]

~Will check it later today.~

Oops, wrong issue.

[melvin-bot[bot]]

@michaelhaxhiu, @sonialiap, @0xmiroslav Whoops! This issue is 2 days overdue. Let's get this updated quick!

[0xmiroslav]

@sonialiap let's clarify the scope to fix in this GH. https://github.com/Expensify/App/issues/23068#issuecomment-1692141049 has clear reproducible step and 2 separate bugs. Should we fix both here or only 2nd bug which is OP?

[melvin-bot[bot]]

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

[sonialiap]

@0xmiroslav I am for expanding the scope if it seems reasonable from the engineering point of view 👍

[melvin-bot[bot]]

@michaelhaxhiu, @sonialiap, @0xmiroslav Whoops! This issue is 2 days overdue. Let's get this updated quick!

[kameshwarnayak]

@0xmiroslav @sonialiap I have update my proposal to address the expanded scope.

Please have a look and let me know if that makes sense.

[sonialiap]

@0xmiroslav I hear you're back, let me know if you've been overwhelmed with issues and I can reassign. But if you're good then bumping my last comment:

I am for expanding the scope if it seems reasonable from the engineering point of view 👍

If you think it's reasonable to expand the scope then do you want to see if any contributors have ideas on the fix for the expanded scope? Maybe ping the person(s) who has the best proposal so far to see if they can expand

[0xmiroslav]

@0xmiroslav I am for expanding the scope if it seems reasonable from the engineering point of view 👍

yes, reasonable to me

[0xmiroslav]

@kameshwarnayak thanks for updated proposal. But your root cause and solution to fix bug 2 is completely wrong.

[0xmiroslav]

@sonialiap we're still waiting proposals to fix both bugs

[kameshwarnayak]

@0xmiroslav You are right. My bad. I misunderstood the second bug. I have updated my proposal with the right root cause and fix to bug 2

Can you please check and let me know if that makes sense?

[melvin-bot[bot]]

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

[0xmiroslav]

Can you please check and let me know if that makes sense?

Still I am not following that solution

[WikusKriek]

Proposal

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

Attachment modal loads forever and after closing attachment modal, it navigates to not found page.

What is the root cause of that problem?

The root cause of the two issues mentioned here https://github.com/Expensify/App/issues/23068#issuecomment-1692141049 is that the user that tries to access the attachment does not have access to the report. This causes props.report to be empty and we land up using AttachmentView instead of AttachmentCarousel. This causes the infinite loading due to not having the correct props for AttachmentView (like the file value).

https://github.com/Expensify/App/blob/b11bddc054f54bb46d5fb5aaf05e25b8a7df7faf/src/components/AttachmentModal.js#L350-L371

We should still use AttachmentCarousel to display the report attachments even though the user does not have access to the report and props.report is empty.

Second issue we are facing with the navigating to the 'not found' page is caused by calling dismissModal with a reportID that the user does not have access to. If we call dismissModal with a reportID parameter we will be navigated back to the parent reportID path. And in this case the user does not have access to that report so we see not found page.

https://github.com/Expensify/App/blob/b11bddc054f54bb46d5fb5aaf05e25b8a7df7faf/src/pages/home/report/ReportAttachments.js#L33

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

For the first issue we need a prop that indicates that the attachment is a Report Attachment. Checking props.report is not a good check here because it can still be a report attachment but the check will fail if the user does not have access. We can add a prop isReportAttachment as an aditional check below. https://github.com/Expensify/App/blob/b11bddc054f54bb46d5fb5aaf05e25b8a7df7faf/src/components/AttachmentModal.js#L350

so that it becomes

{!_.isEmpty(props.report) || props.isReportAttachment ? (

And ensures we call the correct component.

For the second issue we need to be calling dismissModal() with no parameter and this will result in us navigating to the last stack action report the user was on before opening the attachment link. https://github.com/Expensify/App/blob/b11bddc054f54bb46d5fb5aaf05e25b8a7df7faf/src/pages/home/report/ReportAttachments.js#L33

What alternative solutions did you explore? (Optional)

N/A

[kameshwarnayak]

@0xmiroslav - I have pushed the code to this branch. Basically I am using onError handler which we are not using even when the Image fails to load.

To handle the Navigation redirect, I am passing the error variable to Navigation.dismissModal and handling in Navigation.js file

[melvin-bot[bot]]

@michaelhaxhiu, @sonialiap, @0xmiroslav Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[sonialiap]

@0xmiroslav any update?

[0xmiroslav]

I think 1st bug depends on https://github.com/Expensify/App/pull/24210 which fixes https://github.com/Expensify/App/issues/23899. And also a dupe of https://github.com/Expensify/App/issues/23374. After fixing crash, https://github.com/Expensify/App/issues/23374 no longer depends on this issue.

So what I suggest is to fix only 2nd bug here. @sonialiap what do you think?

As a reminder, in https://github.com/Expensify/App/issues/23068#issuecomment-1692141049:

• Infinite loading shows (BUG1)
• App redirects to not accessible chat (BUG2)

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot[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[bot]]

@michaelhaxhiu, @sonialiap, @0xmiroslav Huh... This is 4 days overdue. Who can take care of this?

[sonialiap]

@0xmiroslav that sounds like a good plan to me, just fixing

• App redirects to not accessible chat (BUG2)

[DanutGavrus]

@0xmiroslav I. Are we sure that App redirects to not accessible chat (BUG2) is actually a bug and not intended behavior? As @kameshwarnayak pointed out, pressing on X in the Modal calls Navigation.dismissModal() which says: "if we are not in the target report, we need to navigate to it after dismissing the modal":

https://github.com/Expensify/App/blob/56271f0b1a60a2ea17b418b458648bbdf4fde483/src/libs/Navigation/Navigation.js#L166-L172

Here, targetReportID is the reportID of the other report from which the attachment came, and the app tells us that we do not have access to that, which seems intended.

II. What I think is a bug here, also in deep correlation with this Issue's title, is that if we encounter an error inside a report, pressing on browser's back arrow does not work. For example, add this throw new Error('This is a test error.'); before the final return in the ProfilePage component. Now, open a report -> click up on other's user photo/name -> observe the error page -> click on browser's back button -> observe that the error page is still visible and the back button did not work. Fixing this wouldn't be hard, we may just add the following code in the GenericErrorPage component:

useEffect(() => {
    window.onpopstate = () => {
        resetBoundary();
    }
}, []);

I'm really curious about your feedback regarding both I. and II..

[melvin-bot[bot]]

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

[0xmiroslav]

@DanutGavrus let's imagine you're real user. Don't you think it's bug that clicking image link in chat message to preview image and then closing it redirects to another random chat? I think it's different case from directly visiting url.

So message deep link vs browser deep link

[melvin-bot[bot]]

@michaelhaxhiu, @sonialiap, @0xmiroslav Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[WikusKriek]

@DanutGavrus let's imagine you're real user. Don't you think it's bug that clicking image link in chat message to preview image and then closing it redirects to another random chat? I think it's different case from directly visiting url.

So message deep link vs browser deep link

@0xmiroslav it does not navigate you to a random chat. It navigates the user to the chat of that attachment. This is being done on purpose. There is a specific check for what report you are coming from and what report image you are viewing. If the two report ids do not match it redirects you to the report of the attachment you are viewing when you close the popup. If you have access to that report you will see it but if you don't you will see not found page after the popup is closed. This is why in my proposal I suggested looking at the report.reportID to determine if the user has access or not. If the user does not have access we call Navigation.dismissModal() and we get redirected to the last report we are on before we opened the attachment.

If we do not want to get redirected to the report of the attachment we are viewing when we close the modal, then we should remove that check or call Navigation.dismissModal().

[0xmiroslav]

@WikusKriek to clarify, you suggest:

• redirect to the correct report if image link is valid
• just close modal to go back to the previous report if image link is invalid?

[WikusKriek]

@WikusKriek to clarify, you suggest:

• redirect to the correct report if image link is valid
• just close modal to go back to the previous report if image link is invalid?

This is what I suggested im my proposal yes:

• Open modal and if close redirect to the correct report if user has access to that attachment
• Open modal and if close redirect back to report user was on if the user does not have access to the report of the attachment

But now I am wondering if this redirect to the report of the attachment might have been some legacy code that made sense when it was still a full view. If it is no longer required to do this then I suggest just doing Navigation.dismissModal() as this will return you to the report you were on before opening the modal. Or removing the check in this comment https://github.com/Expensify/App/issues/23068#issuecomment-1725261673 will have the same effect.

[0xmiroslav]

• Open modal and if close redirect to the correct report if user has access to that attachment
• Open modal and if close redirect back to report user was on if the user does not have access to the report of the attachment

I think we should discuss the expected behavior with @Expensify/design

https://github.com/Expensify/App/assets/97473779/d1de084e-0db7-438e-a695-c301f0eabd34

[shawnborton]

Hmm I am having a hard time following along. Can't we just simply fix the fact that the back button isn't working her, per the original bug report?

[WikusKriek]

@shawnborton just some context of the user flow:

1. User clicks an attachment link sent in the chat.
2. They view the attachment, if they have access they see attachment if they dont they see not found.
3. They are done viewing attachment and press close.
4. They are redirected to the report of the attachment they viewed and not the one they were on when clicking the link.

So the problem is 4, if a user was on a report A and a link to an attachment of report B was sent to them. Should they be redirected to report B if they close the attachment modal? And then there is the case where they might not have access to report B and so on closing the modal they are navigated to a report that shows not found.

And I believe the original issue has been resolved by onother PR.

[shawnborton]

Ah, got it. I would be curious to hear our engineers take on this, as this sounds like a nav stack question. cc @Julesssss @marcaaron for thoughts, but I would think you would go back to the place you were before opening the attachment.

[michaelhaxhiu]

note: @sonialiap I'm preparing for sabbatical leave this Friday and going to leave you assigned to this one to see it through 🙏. Thanks for your help here!

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[melvin-bot[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[bot]]

@sonialiap, @0xmiroslav Eep! 4 days overdue now. Issues have feelings too...

[sonialiap]

I cannot reproduce this either. Closing. Please reopen if you can reproduce

[0xmiroslav]

@sonialiap this is still reproducible.

https://github.com/Expensify/App/assets/97473779/7ee3c593-1e19-4a86-92a1-5ff0561388eb

[dhanashree-sawant]

Still able to reproduce on latest staging

[WikusKriek]

@sonialiap can you reopen this issue it is definetely still a problem. See https://github.com/Expensify/App/issues/23068#issuecomment-1733213115 to reproduce.

[tsa321]

@0xmiroslav based on the comment above:

but I would think you would go back to the place you were before opening the attachment.

I think removing reportID parameter in:

https://github.com/Expensify/App/blob/d06d2f75e89e7ba039e34e76d376f6dc59ca5768/src/pages/home/report/ReportAttachments.js#L33

will solve the issue, like @WikusKriek proposed.

This behavior is also similar if we click on for example participant link: http://localhost:8082/r/1111111111111111/participants

[melvin-bot[bot]]

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

[0xmiroslav]

We're still waiting feedback from engineers - https://github.com/Expensify/App/issues/23068#issuecomment-1733221847

[melvin-bot[bot]]

Triggered auto assignment to @jasperhuangg, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[jasperhuangg]

Bump @Julesssss @marcaaron

What's the expected behavior here? Here's some good context on the issue: https://github.com/Expensify/App/issues/23068#issuecomment-1733213115

[Julesssss]

What's the expected behavior here?

I agree with Shawn:

but I would think you would go back to the place you were before opening the attachment.

[marcaaron]

I think I disagree. The error boundary best case scenario is that it never shows at all for any reason. Once the app has crashed it's crashed. Refresh or sign out are the options we give. I don't think we should expect that "going back" will fix whatever problem we experienced any more than we should expect that "going back" will refresh the loaded JS (it won't - it's a single page app and something unexpected happened).