browser.downloads.download() does not send cookies in stricter privacy modes
Categories
(WebExtensions :: General, defect, P5)
Tracking
(Not tracked)
People
(Reporter: nmaier, Unassigned)
References
()
Details
STR:
- Switch your browser Content Blocking to Standard or Strict.
- Start a download with the WebExtensions downloads API to a location that has a cookie set.
- Observe e.g. in the Browser Console that the resulting request contains the cookie header, as expected.
- Switch your browser Content Blocking to Custom and select to block "All third-party Cookies (may cause websites to break)".
- Start a download with the WebExtensions downloads API to a location that has a cookie set.
Expected:
Just like with Standard/Strict Content Blocking, cookies should be sent
Actual:
No cookies sent.
If I recall correctly, I once fixed the same issue years ago in legacy DownThemAll! where we used to set up our own channels similar to what DownloadCore does. The reason this happens is that such directly set up channels generally lack the context (nsILoadInfo) to determine that such channel is not in fact a third-party load.
My guess is that DownloadCopySaver should set nsIHttpChannelInternal.forceAllowThirdPartyCookie to true, just like e.g. the handler for the regular context menu Save Link As does and I did in DownThemAll!, or somehow set up a proper loading info context for the channel.
An alternative approach would be to modify the logic in ThirdPartyUtil to handle nsIContentPolicy::TYPE_SAVEAS_DOWNLOAD differently.
This issue was reported to me in https://github.com/downthemall/downthemall/issues/8#issuecomment-534751511
I'm not sure if this ever worked as expected, and are therefore not sure if this is a regression or not.
|
||
Updated•5 years ago
|
|
||
Comment 1•4 years ago
|
||
When your extension has host permissions (and DTA does), then cookies are already being sent in stricter cookie modes (unit tests added in bug 1621249, overview of relevant bugs in https://bugzilla.mozilla.org/show_bug.cgi?id=1621249#c7).
When an extension does not have host permissions, it may still be affected by rules concerning third-party cookies. That is being addressed in bug 1655190, so I'll mark this as a duplicate of that.
Description
•