-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Handle potential CORS issues during file downloads #25556
Handle potential CORS issues during file downloads #25556
Conversation
src/libs/fileDownload/index.ios.js
Outdated
const attachmentName = FileUtils.appendTimeToFileName(fileName) || FileUtils.getAttachmentName(fileUrl); | ||
const attachmentName = fileName ? FileUtils.appendTimeToFileName(fileName) : FileUtils.getAttachmentName(fileUrl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change here is related to: #23094 (comment)
Should we submit a separate PR
(If we do the current PR won't be testable on iOS and Android)
@aimane-chnaif Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
4fbbe80
to
2791cb1
Compare
Updated with latest changes from |
2791cb1
to
918c72f
Compare
@kidroca please fix these console errors Screen.Recording.2023-10-22.at.8.45.02.PM.movI know this happens on main and not caused by this PR, but let's fix here. Otherwise it will remain forever. (no one will fix it) |
565432c
to
da50bf4
Compare
I've added the following fix: da50bf4e (Also synced 3000+ commits from |
@kidroca conflicts. I will review today |
- Added logic to resolve URLs using `tryResolveUrlFromApiRoot`. - For URLs not originating from the API root (3rd party), leverage the browser's built-in functionality by opening them in a new tab to avoid CORS limitations during direct downloads.
- Addressed issue where attachments, especially those added via drag and drop, lacked the `fileName` attribute, causing download failures. - Enhanced the fallback mechanism to generate file name from URL when `fileName` is missing. - Updated the fileName logic in `fileDownload` across iOS, Android, and web implementations.
da50bf4
to
55e5d64
Compare
Conflicts resolved |
55e5d64
to
9324555
Compare
9324555
to
c1536f9
Compare
Reviewer Checklist
Screenshots/VideosAndroid: Nativeandroid.movAndroid: mWeb Chromemchrome.moviOS: Nativeios.moviOS: mWeb Safarimsafari.movMacOS: Chrome / Safariweb.movMacOS: Desktopdesktop.mov |
mSafari bug: bug.movSeems related to carousel. Out of scope since already happening on main |
I am not able to download android file because of file name (i.e. 2023-11-05 07:55:06.813.jpg) This happens because android.download.mov |
I think we shouldn't have attempted to address the external regressions identified during testing, and that doing so caused significant delays to this PR. Let's acknowledge
|
I agree ^. |
Out of scope issues when file name doesn't exist:
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
@kidroca I think we should not open new tab when download local image (blob). Let's fix that in new PR. Screen.Recording.2023-11-07.at.5.52.58.PM.mov |
Thank you for the suggestion, @aimane-chnaif. I understand the scenario you're pointing out, but I believe it represents a very specific use case. The situation where a user tries to download an attachment they've just uploaded, before the upload process has completed is quite rare in typical user workflows. Moreover, in the event that this does occur, it doesn't seem to cause any errors - the system handles it by re-rendering the attachment once the backend URL is ready, as in the video you've shared. Given that this edge case neither breaks the app nor degrades the user experience significantly, adding extra logic to handle it might unnecessarily complicate handling. Complexity should only be introduced when it's clearly warranted, and in this instance, it seems like it would be for a relatively unlikely scenario. That said, I'm open to hearing more about your concerns. If you feel there are additional factors I might not be considering, or if this is indicative of a larger issue, I'm definitely open to discussing it further. |
Agree it's edge case but it's a bit weird to show |
Also, it doesn't work on desktop app |
🚀 Deployed to staging by https://github.com/jasperhuangg in version: 1.3.96-6 🚀
|
🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.96-15 🚀
|
🚀 Deployed to staging by https://github.com/jasperhuangg in version: 1.3.98-0 🚀
|
🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.98-5 🚀
|
tryResolveUrlFromApiRoot
.Details
Given the security enhancements in browsers, they only permit the click() method on
<a>
elements with a 'download' attribute if invoked directly by user actions. The prior version of the function, which attempted to open it in new tab if the download failed fetched, sometimes led to a delayed user response, and the action was blocked.Fixed Issues
$ #19965
PROPOSAL: #19965 (comment)
Also related: #23094 (comment)
Tests
Scenario 1 - Validate Concierge Drag & Drop Attachments
Objective: Ensure attachments added by Concierge through Drag & Drop are downloadable across platforms.
Prerequisites: A chat session with Concierge.
Steps:
General:
On Web / Desktop:
On iOS / Android(a regression prevents testing this flow in the current PR):Tap on any of the received attachments.Tap the Download button located in the upper right corner.Observation: Unlike web platforms, native apps are unaffected by CORS. As such, the attachment should download directly to the device.Scenario 2 - Confirm Functionality of Regular Attachments
Objective: Ensure that attachments (excluding those from Concierge) are downloadable across all platforms.
Prerequisites: A chat session with an existing attachment (This could be any chat other than with Concierge).
Steps:
Offline tests
N/A - attachments cannot be downloaded while offline
QA Steps
Scenario 1 - Validate Concierge Drag & Drop Attachments
Objective: Ensure attachments added by Concierge through Drag & Drop are downloadable across platforms.
Prerequisites: A chat session with Concierge.
Steps:
General:
On Web / Desktop:
On iOS / Android(a regression prevents testing this flow in the current PR):Tap on any of the received attachments.Tap the Download button located in the upper right corner.Observation: Unlike web platforms, native apps are unaffected by CORS. As such, the attachment should download directly to the device.Scenario 2 - Confirm Functionality of Regular Attachments
Objective: Ensure that attachments (excluding those from Concierge) are downloadable across all platforms.
Prerequisites: A chat session with an existing attachment (This could be any chat other than with Concierge).
Steps:
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
this
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Web
Screen.Recording.2023-08-21.at.10.26.35.mov
Screen.Recording.2023-08-21.at.10.27.04.mov
Mobile Web - Chrome
Android.Emulator.-.Pixel_2_API_29_5554.2023-08-21.21-07-49.mp4
Android.Emulator.-.Pixel_2_API_29_5554.2023-08-21.21-08-24.mp4
Mobile Web - Safari
Screen.Recording.2023-08-21.at.10.16.04.mov
Screen.Recording.2023-08-21.at.10.16.41.mov
Desktop
Screen.Recording.2023-08-21.at.10.33.45.mov
Screen.Recording.2023-08-21.at.10.34.06.mov
iOS
Screen.Recording.2023-08-21.at.11.22.01.mov
Screen.Recording.2023-08-21.at.11.22.24.mov
Android
Screen_recording_20230901_192418.webm
Screen_recording_20230901_192618.webm