[$2000] mWeb/Chrome - Chat -After refresh the page while offline - the composed box is frizzed and message appears in composed box

[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!

---

Issue found when executing PR #11219

Action Performed:

1. Go to staging.new.expensify.com
2. Log in with any account
3. Navigate to a chat
4. Go offline
5. Type a draft comment in the composer, but don’t send it i.e “test”
6. Tap + > Add attachment > Take a picture
7. Click Send
8. Verify “test” appears pending greyed out in the chat
9. Verify “Uploading attachment..” appears pending greyed out in the chat
10. Refresh the mWeb browser
11. Observe the pending message and pending attachment disappear from the chat
12. Observe the pending message appears in the composer
13. Go back online
14. Refresh the mWeb browser again to reload the NewDot page
15. The pending message disappears from the composer
16. The pending message and attachment appear in the chat

Expected Result:

When refreshing the mWeb browser when offline, the pending message and pending attachment should not disappear from the chat. Further, the pending message should not appear in the composer.

Actual Result:

See action steps 10-16 above.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Mobile Web (Android/Chrome)

Version Number: v1.2.39-0

Reproducible in staging?: Yes

Reproducible in production?: Yes

Email or phone of affected tester (no customers): any

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

screen-20221213-143354.mp4

Device reproduced on:

• Chrome v⁦108.0.5359.79
• Android 13 build TP1A.221105.002
• Pixel 5a

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation: related discussion on latest reproduction here.

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @Justicea83 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[Justicea83]

this can be external

[melvin-bot]

Triggered auto assignment to @mallenexpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

📣 @sobitneupane You have been assigned to this job by @Luke9389!
Please apply to this job in Upwork 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 📖

[melvin-bot]

📣 @kbecciv You have been assigned to this job by @Luke9389!
Please apply to this job in Upwork 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 📖

[Luke9389]

Whoops! Sorry for the noise @kbecciv

@Justicea83 I reassigned everyone bc I assumed you unassigned us by mistake.

[mallenexpensify]

posted! https://www.upwork.com/jobs/~01a755aaccee46f8a1

[melvin-bot]

@sobitneupane, @maddylewis, @Luke9389 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[sobitneupane]

An issue for that might even exist already. We'll need to HOLD this one and wait for the other to be resolved before moving forward (and retesting).

I cannot find any issue logged in for this.

[maddylewis]

@Luke9389 - can you provide some clarity on -
#11265 (comment) and #11265 (comment)

thank you!

[maddylewis]

sounds like we're still holding this one:

We'll need to HOLD this one and wait for the other to be resolved before moving forward (and retesting).

[Luke9389]

Ok we just need to verify that the original issues is reproducible, because earlier we couldn't get through all the reproduction steps (my assumption was that there was another bug blocking us from doing so).

@sobitneupane are you able to reproduce this one?

I'll give it a try too.

[Luke9389]

OK so I got confused about this earlier. I agree that we should split this into two issues (and tackle the one where nothing is clickable first).
Before we do that, I'm going to reproduce that and search to see if an issue exists already.

[Luke9389]

When testing this on iOS, I'm not able to reproduce the problem that nothing is clickable after an offline refresh.

In part that's because I get sent back to the homepage after the refresh. That's covered in this issue here. But even then, the UI is definitely clickable. So I think we need to HOLD on that issue. Do you agree @sobitneupane?

[sobitneupane]

@Luke9389 I can still reproduce it on android mWeb/Chrome.

[JmillsExpensify]

Tried to test this via Browserstack, but I couldn't get it to work (Browserstack issue more than anything else).

Regardless though, I feel like this and related issues where a refresh is applied should be held and tackled more holistically. It's also a bit unclear whether this is related to the app navigation reboot (liked the issue @Luke9389 linked), or whether this should be treated independently.

[Luke9389]

I've just attempted to reproduce this one and still can't. Can you post a video with your reproduction @sobitneupane ?

[trjExpensify]

Linking the thread for the breadcrumbs.

@alex-mechler was able to help us reproduce this (❤️). Here are the steps we followed:

1. Go to staging.new.expensify.com
2. Log in with any account
3. Navigate to a chat
4. Go offline
5. Type a draft comment in the composer, but don’t send it i.e “test”
6. Tap + > Add attachment > Take a picture
7. Click Send
8. Verify “test” appears pending greyed out in the chat
9. Verify “Uploading attachment..” appears pending greyed out in the chat
10. Refresh the mWeb browser
11. Observe the pending message and pending attachment disappear from the chat
12. Observe the pending message appears in the composer
13. Go back online
14. Refresh the mWeb browser again to reload the NewDot page
15. The pending message disappears from the composer
16. The pending message and attachment appear in the chat again and upload

Video reproduction:

screen-20221213-143354.mp4

Additional notes:

• If you send the message and attachment separately offline, it works as intended on Android mWeb chrome. Video reproduction here.
• The bug is not reproducible on iOS mWeb Safari & Chrome, Desktop or Web (Chrome) so it's an isolated issue to mWeb chrome on Android only
• I don’t believe this issue is related to anything with the navigation reboot, so it shouldn’t be held on that initiative. It more so seems to be a regression from the Report_AddComment API refactors, or something that never worked as intended on Android mWeb chrome perhaps?
• Given that it’s well over 4 weeks old at this point and potentially related to something in the API refactors this should become Internal. Luke doesn't quite have the bandwidth for it and is posting here for a volunteer.

[sobitneupane]

@alex-mechler Can you please test the following steps:

1. Go offline
2. Reload the page.

After above steps, I can just scroll the app. Nothing can be clicked or pressed.

vidma_recorder_edited_14122022_120340.mp4

[alex-mechler]

I'm seeing the same behavior as that video @sobitneupane

[trjExpensify]

@sobitneupane I think that's a separate issue, but likely the same cause being how Chrome on Android caches an old version of our site after the refresh. Both of which I don't think we're going to solve now.

[Luke9389]

Yeah, after speaking about this one at length last night, @trjExpensify @marcaaron and I have come to the conclusion that this issue falls under "unsupported feature". I'll quote Marc's reasoning for this (apologies for not having that discussion in expensify-open-source where it'd be visible and linkable)

I think we flag this as an “unsupported” feature for now and close anything related to a page that was “reloaded” while offline in Android Chrome. If the repro steps have that then it’s “unsupported”. If we want to support a progressive web app like behavior for our website then we can look into what it takes to do that in the future.

[trjExpensify]

Cool, cool. That was a fun one! Let's go ahead and close this out. I've added it to an issue housing known bugs when we come across them.

Community update here, and QA update here.