Closed Bug 1908629 Opened 4 months ago Closed 4 months ago

Download request does not send the same cookies as normal request

Categories

(Core :: Privacy: Anti-Tracking, defect)

defect

Tracking

()

VERIFIED FIXED
130 Branch
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:

  1. Open https://tmp.fnordig.de/cookies
  2. Reload https://tmp.fnordig.de/cookies. You should see cookie: "hello_world".
  3. Press Ctrl/Cmd-S (or File -> Save Page As) and save the file.
  4. 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.

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.

That is unintentional. I'll get on fixing this regression!

Flags: needinfo?(bvandersloot)

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: nobody → bvandersloot
Status: NEW → ASSIGNED
Pushed by bvandersloot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/26475fc35af3 Download request for JSON viewer documents was partitioned - r=Gijs
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 130 Branch

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: