-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Comments
Triggered auto assignment to @greg-schroeder ( |
We think that this bug might be related to #vip-vsb |
@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 |
ProposalPlease 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. App/src/components/Attachments/AttachmentView/index.tsx Lines 232 to 249 in d519981
After we send the image and open the image preview, this time, App/src/components/Attachments/AttachmentView/index.tsx Lines 126 to 127 in d519981
But we won't focus on that issue because even if
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 Lines 4038 to 4040 in de9cb1f
which will disable the preview.
|
Job added to Upwork: https://www.upwork.com/jobs/~013a2a8877c3c4d06c |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @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. |
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. |
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
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? |
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. |
Thanks for the feedback! We can go with @bernhardoj's initial proposal then. |
Triggered auto assignment to @srikarparsi, see https://stackoverflow.com/c/expensify/questions/7972 for more details. |
I don't have any strong feelings here. Maybe slightly leaning towards what Danny is suggesting here:
|
Sounds good, assigning @bernhardoj |
PR is ready |
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 |
Pending discussion above |
@roryabraham can you help summarize where that discussion landed? I admit I'm a bit unfamiliar with this specific space in the product |
The PR was reverted in the end, I think we can pay out and close this one. |
Ah, word, yeah I see that now |
Payment summary: Contributor: @bernhardoj - $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. |
Requested in ND. |
$250 approved for @bernhardoj |
Requested in ND. |
Seemed that request failed, requested again in ND. |
$250 approved for @Ollyws |
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: v9.0.22-0
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause Internal Team
Action Performed:
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:
Screenshots/Videos
Bug6575727_1724046651606.bandicam_2024-08-19_07-44-40-640.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @OllywsThe text was updated successfully, but these errors were encountered: