[$250] Web - Attachment - Attached long image can be briefly opened in full resolution

[IuliiaHerets]

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: v9.0.22-0 Reproducible in staging?: Y Reproducible in production?: Y Issue reported by: Applause Internal Team

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Log in with any account
3. Open any 1:1 chat
4. Send the attached long image to the chat
5. Quickly open it after it appeared in the chat
6. Zoom in
7. Open the image again after it's closed

Expected Result:

The low resolution image should open for the first time.

Actual Result:

Attached long image can be briefly opened in full resolution.

Workaround:

Unknown

Platforms:

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

https://github.com/user-attachments/assets/0adc937f-cecd-493e-be1d-9462bdeb0bbb

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013a2a8877c3c4d06c
• Upwork Job ID: 1826367055440708714
• Last Price Increase: 2024-08-28

Issue Owner

Current Issue Owner: @Ollyws

[melvin-bot[bot]]

Triggered auto assignment to @greg-schroeder (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.

[IuliiaHerets]

We think that this bug might be related to #vip-vsb

[IuliiaHerets]

@greg-schroeder FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[bernhardoj]

Proposal

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

We can preview the high res image in its full size.

What is the root cause of that problem?

When we first trying to upload the hi-res image, the image preview modal will only show the image icon, file name, and a message that preview is disabled when uploading hi-res image.

https://github.com/Expensify/App/blob/d519981587b065ce96f73ab341d84f9eb17a864c/src/components/Attachments/AttachmentView/index.tsx#L232-L249

After we send the image and open the image preview, this time, isUploaded is true. Before the image is uploaded to the BE, isHighResolution is always false because the file resolution here somehow 0. https://github.com/Expensify/App/blob/d519981587b065ce96f73ab341d84f9eb17a864c/src/components/Attachments/AttachmentView/index.tsx#L126-L127

But we won't focus on that issue because even if isHighResolution is true, the preview source of the local image is the original source of the image. https://github.com/Expensify/App/blob/d519981587b065ce96f73ab341d84f9eb17a864c/src/components/Attachments/AttachmentView/index.tsx#L249

So, the image is shown at its full resolution. Only after the image is uploaded to the BE, the BE returns the preview source that contains a smaller resolution of the file.

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

We can disable previewing the image before it gets uploaded to the BE. To do that, we need to add data-expensify-preview-modal-disabled="true" to the optimistic img tag, https://github.com/Expensify/App/blob/de9cb1f0b33579c143638eba3e4ab5e9af864808/src/libs/ReportUtils.ts#L4038-L4040

which will disable the preview. https://github.com/Expensify/App/blob/de9cb1f0b33579c143638eba3e4ab5e9af864808/src/components/HTMLEngineProvider/HTMLRenderers/ImageRenderer.tsx#L62

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~013a2a8877c3c4d06c

[melvin-bot[bot]]

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

[Ollyws]

@bernhardoj's proposal does make sense, however it will be disabling the image preview until it's updated by the backend, which means that if the image is updated in offline mode we won't be able to preview it until we come back online. Are there any alternative options @bernhardoj?

[bernhardoj]

Hmm, since we want to make it consistent by viewing the smaller resolution of the file before and after upload, the alternative is to compress it locally before uploading it which is not reliable as pointed out here.

The other alternative is to allow the user to open the preview, but shows the regular attachment view just like the preview before sending the image (without the send button).

But I don't think it helps that much because the user still can't preview the real image.

[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? 💸

[Ollyws]

Would be great if @Expensify/design could chime in here as it's a design decision really.

Would it be better that image preview is disabled until there is a response from the server returning the correctly sized image (this would mean there is a small delay in which the thumbnail being clicked will not open the preview window),

or the solution in https://github.com/Expensify/App/issues/47646#issuecomment-2310221117 where we would disable the preview locally if the image is too large and we haven't yet recieved the correctly formatted image from the server?

[dannymcclain]

Keen for other designer's thoughts, but I think I might be leaning towards just not letting them click on it until we receive the correctly sized image.

I almost thought that letting them open it and showing them this screen again (without the upload button) would make sense since it seems like the image is still kind of uploading in a way, but it's such a pointless thing to look at it might make more sense just to not let them click on the thumbnail until they can actually see something.

[shawnborton]

I don't feel strongly, I see what you are saying about using the same "You can't see this" modal while we still wait for it to properly upload. I think that feels like it would be the most consistent.

[Ollyws]

Thanks for the feedback! We can go with @bernhardoj's initial proposal then. 🎀👀🎀 C+ reviewed

[melvin-bot[bot]]

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

[dubielzyk-expensify]

I don't have any strong feelings here. Maybe slightly leaning towards what Danny is suggesting here:

but it's such a pointless thing to look at it might make more sense just to not let them click on the thumbnail until they can actually see something.

[srikarparsi]

Sounds good, assigning @bernhardoj

[bernhardoj]

PR is ready cc: @Ollyws

[roryabraham]

Whoa, I think we took the solution much too far for this edge-case issue by disabling all local/offline image previews we spent years building in https://github.com/Expensify/App/pull/44889.

I know we tagged design in here on this big decision, but I feel pretty strongly that we should revert this and go back to the drawing board on solutions.

Brought this up with the team in slack here

[greg-schroeder]

Pending discussion above

[greg-schroeder]

@roryabraham can you help summarize where that discussion landed? I admit I'm a bit unfamiliar with this specific space in the product

[Ollyws]

The PR was reverted in the end, I think we can pay out and close this one.

[greg-schroeder]

Ah, word, yeah I see that now

[greg-schroeder]

Payment summary:

Contributor: @bernhardoj - $250 - You can make a manual request via ND C+: @Ollyws - $250 - You can make a manual request via ND

This was reverted, but not because of a bug or anything like that - we just decided not to go this route after saying we wanted to originally.

[bernhardoj]

Requested in ND.

[JmillsExpensify]

$250 approved for @bernhardoj

[Ollyws]

Requested in ND.

[Ollyws]

Seemed that request failed, requested again in ND.

[garrettmknight]

$250 approved for @Ollyws