Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 of 6 tasks
IuliiaHerets opened this issue Aug 19, 2024 · 28 comments
Closed
1 of 6 tasks
Assignees
Labels
Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Reviewing Has a PR in review Weekly KSv2

Comments

@IuliiaHerets
Copy link

IuliiaHerets commented Aug 19, 2024

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
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Bug6575727_1724046651606.bandicam_2024-08-19_07-44-40-640.mp4

Bug6575727_1724046927643!bigggg (1)

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 OwnerCurrent Issue Owner: @Ollyws
@IuliiaHerets IuliiaHerets added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Aug 19, 2024
Copy link

melvin-bot bot commented Aug 19, 2024

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
Copy link
Author

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

@IuliiaHerets
Copy link
Author

@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
Copy link
Contributor

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.

if (isHighResolution) {
if (!isUploaded) {
return (
<>
<View style={styles.imageModalImageCenterContainer}>
<DefaultAttachmentView
icon={Expensicons.Gallery}
fileName={file?.name}
shouldShowDownloadIcon={shouldShowDownloadIcon}
shouldShowLoadingSpinnerIcon={shouldShowLoadingSpinnerIcon}
containerStyles={containerStyles}
/>
</View>
<HighResolutionInfo isUploaded={isUploaded} />
</>
);
}
imageSource = previewSource?.toString() ?? imageSource;

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.

FileUtils.getFileResolution(file).then((resolution) => {
setIsHighResolution(FileUtils.isHighResolutionImage(resolution));

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.

imageSource = previewSource?.toString() ?? imageSource;

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,

App/src/libs/ReportUtils.ts

Lines 4038 to 4040 in de9cb1f

if (file.type?.startsWith('image')) {
return `<img src="${file.uri}" alt="${file.name}" ${dataAttributes} />`;
}

which will disable the preview.

const imagePreviewModalDisabled = htmlAttribs['data-expensify-preview-modal-disabled'] === 'true';

@melvin-bot melvin-bot bot added the Overdue label Aug 21, 2024
@greg-schroeder greg-schroeder added the External Added to denote the issue can be worked on by a contributor label Aug 21, 2024
@melvin-bot melvin-bot bot changed the title Web - Attachment - Attached long image can be briefly opened in full resolution [$250] Web - Attachment - Attached long image can be briefly opened in full resolution Aug 21, 2024
Copy link

melvin-bot bot commented Aug 21, 2024

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

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Aug 21, 2024
Copy link

melvin-bot bot commented Aug 21, 2024

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

@melvin-bot melvin-bot bot removed the Overdue label Aug 21, 2024
@Ollyws
Copy link
Contributor

Ollyws commented Aug 26, 2024

@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
Copy link
Contributor

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).
image

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

Copy link

melvin-bot bot commented Aug 28, 2024

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

@melvin-bot melvin-bot bot added the Overdue label Aug 28, 2024
@Ollyws
Copy link
Contributor

Ollyws commented Aug 28, 2024

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 #47646 (comment) 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?

@melvin-bot melvin-bot bot removed the Overdue label Aug 28, 2024
@dannymcclain
Copy link
Contributor

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)
image
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
Copy link
Contributor

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
Copy link
Contributor

Ollyws commented Aug 28, 2024

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

Copy link

melvin-bot bot commented Aug 28, 2024

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

@dubielzyk-expensify
Copy link
Contributor

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
Copy link
Contributor

Sounds good, assigning @bernhardoj

@melvin-bot melvin-bot bot removed the Help Wanted Apply this label when an issue is open to proposals by contributors label Aug 29, 2024
@melvin-bot melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Daily KSv2 labels Aug 29, 2024
@bernhardoj
Copy link
Contributor

PR is ready
cc: @Ollyws

@roryabraham
Copy link
Contributor

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 #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
Copy link
Contributor

Pending discussion above

@greg-schroeder
Copy link
Contributor

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

@Ollyws
Copy link
Contributor

Ollyws commented Sep 17, 2024

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

@greg-schroeder
Copy link
Contributor

Ah, word, yeah I see that now

@greg-schroeder
Copy link
Contributor

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
Copy link
Contributor

Requested in ND.

@JmillsExpensify
Copy link

$250 approved for @bernhardoj

@Ollyws
Copy link
Contributor

Ollyws commented Sep 19, 2024

Requested in ND.

@Ollyws
Copy link
Contributor

Ollyws commented Sep 21, 2024

Seemed that request failed, requested again in ND.

@garrettmknight
Copy link
Contributor

$250 approved for @Ollyws

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Reviewing Has a PR in review Weekly KSv2
Projects
None yet
Development

No branches or pull requests