Download request does not send the same cookies as normal request
Categories
(Core :: Privacy: Anti-Tracking, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox128 | --- | unaffected |
firefox129 | --- | unaffected |
firefox130 | --- | verified |
firefox131 | --- | verified |
People
(Reporter: janerik, Assigned: bvandersloot)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
It seems cookies are not attached to the request when trying to save a document.
I built a tiny reproducer case using my own server. No auth required, just cookies.
STR:
- Open https://tmp.fnordig.de/cookies
- Reload https://tmp.fnordig.de/cookies. You should see
cookie: "hello_world"
. - Press Ctrl/Cmd-S (or File -> Save Page As) and save the file.
- Check what's in the saved
cookies.json
Expected: { "cookie": "hello_world" }
Actual: { "cookie": "" }
.
I used mozregression to track this down (I knew it worked yesterday), which led me to bug 1905289. Seems that patch causes the cookies to not be submitted when saving and I guess that's unintentional.
Comment 1•4 months ago
|
||
Set release status flags based on info from the regressing bug 1905289
:bvandersloot, since you are the author of the regressor, bug 1905289, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 2•4 months ago
|
||
That is unintentional. I'll get on fixing this regression!
Assignee | ||
Comment 3•4 months ago
|
||
This seems to only affect document saves that save as a URL. So it affects the JSON viewer, but if you loaded those cookies in a HTML document and saved that, it works still. This was key to understanding.
Basically when you save the document it uses the document's principal as the triggering principal. That seems right, but for your JSON viewer, the documentURL is the JSON file's url but the principal of the document is (rightly) resource://devtools/client/jsonview/
. So this ends up being partitioned because it is like this is being loaded in a third-party context. I can fix this by constructing the right principal in this corner case, similar to how view-source does it.
Regardless, a fix is coming shortly.
Assignee | ||
Comment 4•4 months ago
|
||
Updated•4 months ago
|
Updated•3 months ago
|
Comment 7•3 months ago
|
||
Issue is reproducible on a 2024-07-18 Nightly build on Windows 10.
Verified as fixed on Firefox 130.0b2 and Firefox Nightly 131.0a1 on Windows 10, Ubuntu 22, macOS 14.
Description
•