1561654 - browser.downloads.download(...) misses cookie-Header

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P1)

Description

[Michael]

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.

Comment 1

[Michael]

Attachment: testbrowserdownloads-1.0.zip

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).

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #3)

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit [auto_nag
documentation](https://wiki.mozilla.org/Release_Management/autonag#workflow.
2Fno_priority.py).

Waiting on QA help here.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Michael]

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.

Comment 9

[Alice0775 White]

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

Comment 11

[Tomislav Jovanovic :zombie]

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.

Comment 12

[Tomislav Jovanovic :zombie]

Attachment: Bug 1561654 - Add contentPolicyType to DownloadCore to enable sending cookies

Also stop opting-out Downloads tests from real behavior.

Comment 13

[Tomislav Jovanovic :zombie]

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

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/40c9b3841232
Add contentPolicyType to DownloadCore to enable sending cookies r=mak,baku,robwu

Comment 15

[Daniel Varga [:dvarga]]

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

Comment 16

[Tomislav Jovanovic :zombie]

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 17

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 20

[Michael]

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

Comment 21

[Tomislav Jovanovic :zombie]

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?

Comment 22

[TheRave]

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

Comment 23

[Victor Carciu]

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.

Comment 24

[Victor Carciu]

Attachment: Postfix Screenshot - FF68 vs FF70

Comment 25

[Michael]

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!

Comment 26

[Tomislav Jovanovic :zombie]

No problem Michael, thanks for double-checking.

Comment 29

[Ostap Bender]

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.