User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Calling browser.downloads.download(...) in a WebExtension, f.e.

browser.downloads.download({
url: "http://localhost:8080/download/file.do",
filename: "whatever/you/want.pdf",
conflictAction: 'uniquify',
});

Actual results:

The cookie-Header (for a session cookie) wasn't set in the request.

Trying to set the header manually in browser.downloads.download(...) leads to a error message: "Error: Forbidden request header name"

Expected results:

The documentation says:

"If the specified url uses the HTTP or HTTPS protocol, then the request will include all cookies currently set for its hostname."

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/downloads/download

It works in Firefox <= 66 and stopped working in Firefox 67; also current Firefox 68 Beta doesn't work for me.

I added a minimal extension which I used to further investigate the bug (to verify its not a problem of our extension itself)

Basically it's just one small background script now that has the following lines of code (build with webpack):

console.log('browser.downloads.download(...)');
browser.downloads.download({
    method: 'GET',
    url: 'http://localhost:8080/download.do',
    filename: 'path/to/file.pdf',
    conflictAction: 'uniquify'
}).then(id => {
    console.log(id);
}).catch(error => {
    console.log(error);
});

Executing this addon with Firefox 66.x or below, everything works as expected. When I use Firefox 67 the Request to http://localhost:8080/download.do (I used a minimal Spring Boot Application for Testing) doesn't get any cookie information (Cookie Header isn't set).

I used about:debugging to load the addon temporary (and without signing).

Can I do anything to help you to identify & fix this bug?
I see the status for firefox68 changed to "wontfix". What does it mean for Firefox 68 ESR, because this would be important for our customers.

Reporter: Would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to figure out when this broke?

Regression points to bug 1525245, marking as P1.

(In reply to Michael from comment #8)

I see the status for firefox68 changed to "wontfix". What does it mean for Firefox 68 ESR, because this would be important for our customers.

This only acknowledges it didn't get fixed in time for 68, but we can uplift to the next ERS 68.x when we fix this in firefox.

Also stop opting-out Downloads tests from real behavior.

References:

1. https://searchfox.org/mozilla-central/rev/0bcdfa9/browser/base/content/nsContextMenu.js#1568
2. https://hg.mozilla.org/mozilla-central/diff/f7a3740/toolkit/components/downloads/test/unit/test_DownloadCore.js

https://hg.mozilla.org/mozilla-central/rev/40c9b3841232

Comment on attachment 9081055 [details]
Bug 1561654 - Add contentPolicyType to DownloadCore to enable sending cookies

Beta/Release Uplift Approval Request

• User impact if declined: Functionality of extensions to download from certain sites is broken.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): A single line change that's fairly well understood and is covered by tests in (now) 2 suites.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This was a regression in 67 right before ESR68, and we are fairly early in the ESR cycle, which makes this an easy win with large payoff.
• User impact if declined: Functionality of extensions to download from certain sites is broken.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): A single line change that's fairly well understood and is covered by tests in (now) 2 suites.
• String or UUID changes made by this patch:

Comment on attachment 9081055 [details]
Bug 1561654 - Add contentPolicyType to DownloadCore to enable sending cookies

Fixes a regression in WebExtension download APIs causing problems for some extensions. Approved for 69.0b10 and 68.1esr.

https://hg.mozilla.org/releases/mozilla-beta/rev/20d10613f363

https://hg.mozilla.org/releases/mozilla-esr68/rev/0435d1ef05ce

I just checked with our addon and the latest beta 69.0b10 and nighly build. If I understand correctly, it should be fixed in that version. We still get a status code 403 when trying to download documents using browser.downloads.download(...)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

I manually verified this should work, at least in current Nightly, I'm not sure there was a beta build since this landed.

Can you please provide a full STR starting from a fresh profile and yesterday's Nightly?

Bug 1548585 is also not fixed with this bug. Maybe that is why he still get the code 403.

Verified as fixed in latest FF70, FF69 and ESR68 using Win10x64 and MacOS 10.13.6. I was also able to see that the bug was reproducible in affected versions.

Please see postfix screenshot.

If this can be reproduced using another steps, please feel free to re-open, but with the steps described in bug description, issue is not reproducible anymore.

Ok, whatever happened before, its working now with the current nightly and 69.0b11. Sorry for any confusion and inconvenience may happened because of my last post.

Our QA has still to confirm the bugfix for our addon. I am just a developer, but at least "it works on my machine" :-)
Thanks a lot for all your effort and time!

No problem Michael, thanks for double-checking.

The nightly version of Firefox no longer sends the Cookie header. As long as it had an old saved cookie with an expired session id, it sent that one but after I deleted it, it no longer sends anything. Firefox version is: 71.0.a1 2019-10-20
This is preventing my extension from downloading.

It does not seem to be the same as 1583715 as my tracking protection is set to Standard.