1691907 - Image downloader extensions fail to use cache with network partitioning enabled, re-download attempts more likely to result in failure

Status: RESOLVED FIXED

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

Description

[Kestrel]

STR:

1. Make sure privacy.partition.network_state = true.
2. Install Cute Save Button or Image Picka.
3. Visit https://www.pixiv.net/en/artworks/22647957 and try to save the main image.

Expected:

Main image saved from cache.

Actual:

Image save fails. With network partitioning disabled the extensions could save from the cache at least once before subsequently failing with 403 Forbidden on further attempts. With network partitioning enabled the cache is never used and all download attempts are forbidden due to lack of a referer.

Without being able to utilize the cache, the image needs to be re-downloaded which is wasteful and has a higher chance of failure due to missing some extra information like a referer.

Comment 1

[Steven DeTar [:sdetar]]

Jens, could you or someone on your team take a look at this bug?

Comment 2

[Jens Stutte [:jstutte]]

I see noone involved from my team in the regressing bugs. Tim, Andrea?

Comment 3

[Tim Huang[:timhuang]]

My speculation is that the extension doesn't use the correct partitionKey when download the content. So, it cannot access the partitioned cache, which leads to this failure.

My thinking is that we might need to modify our extension API to get the correct partitionKey. I will look into that.

Comment 4

[eight04]

FWIW, just investigated pixiv issue few hours ago (before I found this thread) and tested the cache behavior on different browsers. Here is the result:
https://github.com/eight04/webext-hit-the-cache

Comment 5

[Tim Huang[:timhuang]]

Rob, I think this is similar to Bug 1669716. The downloads API doesn't support setting the originAttributes. As the result, the downloading channel won't use a correct partitionKey so it won't access the right cache when downloading the resource.

I am not sure how could we resolve this issue. Ideally, we should hide this from developers and figure out the correct partitionKey for them. But, it looks difficult to me because the download API doesn't aware of the node it downloads.

As an alternative, We could add the support of setting the partitionKey or originAttributs in the download options. But I don't know if this is ideal for an addon developer to figure out the correct 'partitionKey'.

What do you think about this? Do you think we should expose the originAttributes for Download API?

Comment 6

[Rob Wu [:robwu]]

Are dFPI and cache partitioning equivalent?

How is this problem solved for the default download internals (e.g. downloads initiated via the context menu)? I don't see a reference to "origin attributes" or "partitionKey" in DownloadCore.jsm, and not even in the downloads/ component: https://searchfox.org/mozilla-central/search?q=origin+%3FAttributes%7CpartitionKey&path=components%2Fdownload&case=false&regexp=true

If possible, I think that we should try to choose the most likely partitionKey by default, e.g. by creating a partitionKey from the given URL when the feature is enabled. That's a similar approach to https://bugzilla.mozilla.org/show_bug.cgi?id=1689752#c11 for bug 1689752 (which in turn refers to another bug).

Bug 1670278 may be a more generic solution to this, without requiring us to expose all odd details of originAttributes to extensions.

In bug 1669716 I was thinking of repurposing firstPartyDomain to mean "partitionKey" when dFPI is enabled (and firstPartyDomain from FPI otherwise). If for some reason we are unable to automatically select a domain, and if bug 1670278 isn't possible, then I'm not immediately opposed to adding a firstPartyDomain property to the downloads.download API. I just worry that the one extra property isn't a long-term solution, because we keep adding more origin attributes.

Comment 7

[eight04]

For our case (Image Picka), we like to access the image before sending it to downloads API. Here is the workflow:

1. fetch() images.
2. Check if it succeeded or not.
3. Display images to the user and the user selects which to download.
4. Send blob URL to downloads API.

It would be best to hit the cache in step (1).

Comment 8

[Rob Wu [:robwu]]

(In reply to eight04 from comment #7)

For our case (Image Picka), we like to access the image before sending it to downloads API. Here is the workflow:

1. fetch() images.

That's not this bug, but bug 1670278.

Comment 9

[Tim Huang[:timhuang]]

(In reply to Rob Wu [:robwu] from comment #6)

Are dFPI and cache partitioning equivalent?

They are based the same mechanism, i.e. using the partitionKey in OAs to partition storage and network cache. But they are slightly different in two aspects.

• The scope is different. dFPI applies to only third-party contexts but cache partitioning (network partitioning) applies to every context including the first-party context
• dFPI only works for storage and cache partitioning works for caches.

How is this problem solved for the default download internals (e.g. downloads initiated via the context menu)? I don't see a reference to "origin attributes" or "partitionKey" in DownloadCore.jsm, and not even in the downloads/ component: https://searchfox.org/mozilla-central/search?q=origin+%3FAttributes%7CpartitionKey&path=components%2Fdownload&case=false&regexp=true

For the default download internals, they are using the nsIWebBrowserPersist.savePrivacyAwareURI() to save the resource. We would pass the correct cookieJarSettings to the API. The cookieJarSetting has the partitionKey so that we can use it when accessing the network cache.

If possible, I think that we should try to choose the most likely partitionKey by default, e.g. by creating a partitionKey from the given URL when the feature is enabled. That's a similar approach to https://bugzilla.mozilla.org/show_bug.cgi?id=1689752#c11 for bug 1689752 (which in turn refers to another bug).

I think this is the right direction. But using the given URL as partitionKey might be incorrect in the case where the resource is in a third-party context. For example, downloading a URL from foo.com which was loaded in an iframe under bar.com. In this case, we should use the bar.com as the partitionKey in order to access the right cache. But if we use the given URL, then the key will be foo.com.

Maybe we can generate the key from the tab where triggers the download if we know it comes from a content script. For background script, we can still use the given URL as the key. Do you think this is possible?

Bug 1670278 may be a more generic solution to this, without requiring us to expose all odd details of originAttributes to extensions.

If I understand correctly about your solution, it's similar to what I proposed above, right?

In bug 1669716 I was thinking of repurposing firstPartyDomain to mean "partitionKey" when dFPI is enabled (and firstPartyDomain from FPI otherwise). If for some reason we are unable to automatically select a domain, and if bug 1670278 isn't possible, then I'm not immediately opposed to adding a firstPartyDomain property to the downloads.download API. I just worry that the one extra property isn't a long-term solution, because we keep adding more origin attributes.

Yeah, I agree with you about this that we should not add more OAs to developers. This would make them confused.

Comment 10

[Tim Huang[:timhuang]]

(In reply to Tim Huang[:timhuang] from comment #9)

Maybe we can generate the key from the tab where triggers the download if we know it comes from a content script. For background script, we can still use the given URL as the key. Do you think this is possible?

Rob, do you think if this is a valid approach to resolve this issue? Thanks.

Comment 11

[Rob Wu [:robwu]]

(In reply to Tim Huang[:timhuang] from comment #9)

(In reply to Rob Wu [:robwu] from comment #6)

Are dFPI and cache partitioning equivalent?

They are based the same mechanism, i.e. using the partitionKey in OAs to partition storage and network cache. But they are slightly different in two aspects.

• The scope is different. dFPI applies to only third-party contexts but cache partitioning (network partitioning) applies to every context including the first-party context
• dFPI only works for storage and cache partitioning works for caches.

Since partitionKey is used as the underlying key to differentiate the storages, is it possible to use one (new) property in the API (e.g. firstPartyDomain to internally map to partitionKey) to support the desired level of control over selection of storage?

I was hoping that it's possible to do this:

• when the property (e.g. firstPartyDomain) is not set, default to select the partitionKey (treat as first-party) --- this can be done even if we don't introduce a new property to the downloads API.
• if the extension wants to customize the behavior, set the property (e.g. firstPartyDomain)

This can only work if it we can reliably select the "right" values for OA.firstPartyDomain and OA.partitionKey based on the preferences, URL and optional extension-defined "firstPartyDomain" ("property").

I think this is the right direction. But using the given URL as partitionKey might be incorrect in the case where the resource is in a third-party context. For example, downloading a URL from foo.com which was loaded in an iframe under bar.com. In this case, we should use the bar.com as the partitionKey in order to access the right cache. But if we use the given URL, then the key will be foo.com.

Maybe we can generate the key from the tab where triggers the download if we know it comes from a content script. For background script, we can still use the given URL as the key. Do you think this is possible?

The downloads API is only available to extension pages, which don't have the context of the content script. So the first suggestion doesn't work, but the comment about the background script might. It is similar to what I described above, just treating the request as first-party in the decision tree that guides the generation of partitionKey.

The extension API currently has the tabId + frameId properties to uniquely identify a frame, and that could potentially be used to auto-detect the right settings based on the frame (at the small risk of the frame having been navigated and not matching the original intention any more).

Bug 1670278 may be a more generic solution to this, without requiring us to expose all odd details of originAttributes to extensions.

If I understand correctly about your solution, it's similar to what I proposed above, right?

Conceptually yes. I would like to have a way to automatically derive the right properties. Whether by having an API to determine the settings (and passing said settings to an extension API), or by having an opaque value that we internally use to find the right settings.

In bug 1669716 I was thinking of repurposing firstPartyDomain to mean "partitionKey" when dFPI is enabled (and firstPartyDomain from FPI otherwise). If for some reason we are unable to automatically select a domain, and if bug 1670278 isn't possible, then I'm not immediately opposed to adding a firstPartyDomain property to the downloads.download API. I just worry that the one extra property isn't a long-term solution, because we keep adding more origin attributes.

Yeah, I agree with you about this that we should not add more OAs to developers. This would make them confused.

firstPartyDomain is already a known concept in the cookies extension API, so if we are able to describe reasonable rules for how the property is used (and that this always results in the desired result), then I'd rather add the property, than to have a broken extension API for many releases (the API is functionally broken; waiting for the ideal solution to bug 1670278 may take a while).

Comment 12

[Rob Wu [:robwu]]

adding needinfo to make it clear that I've asked a question in comment #11 regarding the feasibility of introducing one new property ("firstPartyDomain") to resolve this bug.

Comment 13

[Tim Huang[:timhuang]]

(In reply to Rob Wu [:robwu] from comment #11)

Since partitionKey is used as the underlying key to differentiate the storages, is it possible to use one (new) property in the API (e.g. firstPartyDomain to internally map to partitionKey) to support the desired level of control over selection of storage?

I was hoping that it's possible to do this:

• when the property (e.g. firstPartyDomain) is not set, default to select the partitionKey (treat as first-party) --- this can be done even if we don't introduce a new property to the downloads API.
• if the extension wants to customize the behavior, set the property (e.g. firstPartyDomain)

I think we can derive the right setting without adding the new property for downloads API. It's because the partitionKey is always set for network requests. And the problem here is that the download API couldn't access the right network cache without the right partitionKey. So, the only thing we need to do here is to get and use the right key. Unless we want to allow the FPI network cache to be accessed even if the FPI is disabled. Then, adding the new property would make sense to me. Otherwise, I think we should keep this simple.

This can only work if it we can reliably select the "right" values for OA.firstPartyDomain and OA.partitionKey based on the preferences, URL and optional extension-defined "firstPartyDomain" ("property").

For OA.partitionKey, we have to set it because it's always set when network partitioning is enabled, and the OA.firstPartyDomain should be set only when FPI is enabled. Note that the partitionKey is not set directly to the OA for the network request. It has to be set to the cookieJarSettings of the network request. Then, Necko will update the OA when accessing network states(i.e. caches, network pool, etc).

I think this is the right direction. But using the given URL as partitionKey might be incorrect in the case where the resource is in a third-party context. For example, downloading a URL from foo.com which was loaded in an iframe under bar.com. In this case, we should use the bar.com as the partitionKey in order to access the right cache. But if we use the given URL, then the key will be foo.com.

Maybe we can generate the key from the tab where triggers the download if we know it comes from a content script. For background script, we can still use the given URL as the key. Do you think this is possible?

The downloads API is only available to extension pages, which don't have the context of the content script. So the first suggestion doesn't work, but the comment about the background script might. It is similar to what I described above, just treating the request as first-party in the decision tree that guides the generation of partitionKey.

The extension API currently has the tabId + frameId properties to uniquely identify a frame, and that could potentially be used to auto-detect the right settings based on the frame (at the small risk of the frame having been navigated and not matching the original intention any more).

This sounds like a valid way to decide the partitionKey to me. If you don't mind, I would like to take this bug and implement this.

Bug 1670278 may be a more generic solution to this, without requiring us to expose all odd details of originAttributes to extensions.

If I understand correctly about your solution, it's similar to what I proposed above, right?

Conceptually yes. I would like to have a way to automatically derive the right properties. Whether by having an API to determine the settings (and passing said settings to an extension API), or by having an opaque value that we internally use to find the right settings.

In bug 1669716 I was thinking of repurposing firstPartyDomain to mean "partitionKey" when dFPI is enabled (and firstPartyDomain from FPI otherwise). If for some reason we are unable to automatically select a domain, and if bug 1670278 isn't possible, then I'm not immediately opposed to adding a firstPartyDomain property to the downloads.download API. I just worry that the one extra property isn't a long-term solution, because we keep adding more origin attributes.

Yeah, I agree with you about this that we should not add more OAs to developers. This would make them confused.

firstPartyDomain is already a known concept in the cookies extension API, so if we are able to describe reasonable rules for how the property is used (and that this always results in the desired result), then I'd rather add the property, than to have a broken extension API for many releases (the API is functionally broken; waiting for the ideal solution to bug 1670278 may take a while).

Given that we can auto-detect the right key by using the tabId + frameId, do you still think we need to add this new property?

Comment 14

[Rob Wu [:robwu]]

(In reply to Tim Huang[:timhuang] from comment #13)

(In reply to Rob Wu [:robwu] from comment #11)

Since partitionKey is used as the underlying key to differentiate the storages, is it possible to use one (new) property in the API (e.g. firstPartyDomain to internally map to partitionKey) to support the desired level of control over selection of storage?

I was hoping that it's possible to do this:

• when the property (e.g. firstPartyDomain) is not set, default to select the partitionKey (treat as first-party) --- this can be done even if we don't introduce a new property to the downloads API.
• if the extension wants to customize the behavior, set the property (e.g. firstPartyDomain)

I think we can derive the right setting without adding the new property for downloads API. It's because the partitionKey is always set for network requests. And the problem here is that the download API couldn't access the right network cache without the right partitionKey. So, the only thing we need to do here is to get and use the right key. Unless we want to allow the FPI network cache to be accessed even if the FPI is disabled. Then, adding the new property would make sense to me. Otherwise, I think we should keep this simple.

If it's possible to fix the bug without new properties, then I'm very much in favor of that, primarily because it unbreaks extensions without requiring them to update (and the API is simpler).
It however seems that you're requesting a new key in the next sentence (whether it's called partitionKey or firstPartyDomain doesn't really matter for the implementation; that's just a question of extension API design).

This can only work if it we can reliably select the "right" values for OA.firstPartyDomain and OA.partitionKey based on the preferences, URL and optional extension-defined "firstPartyDomain" ("property").

For OA.partitionKey, we have to set it because it's always set when network partitioning is enabled, and the OA.firstPartyDomain should be set only when FPI is enabled. Note that the partitionKey is not set directly to the OA for the network request. It has to be set to the cookieJarSettings of the network request. Then, Necko will update the OA when accessing network states(i.e. caches, network pool, etc).

Based on this, I suppose that we can treat the download as first-party by default to fix the common case? At least until we've figured out a better API that offers more control.

The extension API currently has the tabId + frameId properties to uniquely identify a frame, and that could potentially be used to auto-detect the right settings based on the frame (at the small risk of the frame having been navigated and not matching the original intention any more).

This sounds like a valid way to decide the partitionKey to me. If you don't mind, I would like to take this bug and implement this.

I want to discuss this with my team before proceeding (tomorrow is the next opportunity to do so). Note that in the interest of API consistency, the chosen design for this bug should ideally be generic enough to support bug 1670278.

To that end, I am thinking of a new key "requestInitiator" that takes a dictionary, initially tabId + frameId. This is a dictionary a new key to allow reuse across APIs, and a dictionary because it allows future extensions, such as specifying "url" (instead of tabId/frameId).

browser.downloads.download({
  url: ...,
  requestInitiator: { // <-- new name.
    tabId: ...,
    frameId: ...,
  },
});

At the introduction of this new property, we must also account for what we want when conflicting properties are set, such as requestInitiator + incognito (private browsing mode).

firstPartyDomain is already a known concept in the cookies extension API, so if we are able to describe reasonable rules for how the property is used (and that this always results in the desired result), then I'd rather add the property, than to have a broken extension API for many releases (the API is functionally broken; waiting for the ideal solution to bug 1670278 may take a while).

Given that we can auto-detect the right key by using the tabId + frameId, do you still think we need to add this new property?

If we're going to proceed with a superior alternative that fully covers the use case of the new property, then no, the additional property isn't necessary.

Comment 15

[Tim Huang[:timhuang]]

(In reply to Rob Wu [:robwu] from comment #14)

(In reply to Tim Huang[:timhuang] from comment #13)

(In reply to Rob Wu [:robwu] from comment #11)

Since partitionKey is used as the underlying key to differentiate the storages, is it possible to use one (new) property in the API (e.g. firstPartyDomain to internally map to partitionKey) to support the desired level of control over selection of storage?

I was hoping that it's possible to do this:

• when the property (e.g. firstPartyDomain) is not set, default to select the partitionKey (treat as first-party) --- this can be done even if we don't introduce a new property to the downloads API.
• if the extension wants to customize the behavior, set the property (e.g. firstPartyDomain)

I think we can derive the right setting without adding the new property for downloads API. It's because the partitionKey is always set for network requests. And the problem here is that the download API couldn't access the right network cache without the right partitionKey. So, the only thing we need to do here is to get and use the right key. Unless we want to allow the FPI network cache to be accessed even if the FPI is disabled. Then, adding the new property would make sense to me. Otherwise, I think we should keep this simple.

If it's possible to fix the bug without new properties, then I'm very much in favor of that, primarily because it unbreaks extensions without requiring them to update (and the API is simpler).
It however seems that you're requesting a new key in the next sentence (whether it's called partitionKey or firstPartyDomain doesn't really matter for the implementation; that's just a question of extension API design).

My thought was that maybe we can derive the key from the currently active tab, i.e. tabTracker.activeTab. But, perhaps, this is not always the case if the download was not meant to be related to a tab. So, this means that the API needs to be provided a certain hint to allow us to select the correct key, just like what you proposed below, i.e. requestInitiator.

This can only work if it we can reliably select the "right" values for OA.firstPartyDomain and OA.partitionKey based on the preferences, URL and optional extension-defined "firstPartyDomain" ("property").

For OA.partitionKey, we have to set it because it's always set when network partitioning is enabled, and the OA.firstPartyDomain should be set only when FPI is enabled. Note that the partitionKey is not set directly to the OA for the network request. It has to be set to the cookieJarSettings of the network request. Then, Necko will update the OA when accessing network states(i.e. caches, network pool, etc).

Based on this, I suppose that we can treat the download as first-party by default to fix the common case? At least until we've figured out a better API that offers more control.

The extension API currently has the tabId + frameId properties to uniquely identify a frame, and that could potentially be used to auto-detect the right settings based on the frame (at the small risk of the frame having been navigated and not matching the original intention any more).

This sounds like a valid way to decide the partitionKey to me. If you don't mind, I would like to take this bug and implement this.

I want to discuss this with my team before proceeding (tomorrow is the next opportunity to do so). Note that in the interest of API consistency, the chosen design for this bug should ideally be generic enough to support bug 1670278.

To that end, I am thinking of a new key "requestInitiator" that takes a dictionary, initially tabId + frameId. This is a dictionary a new key to allow reuse across APIs, and a dictionary because it allows future extensions, such as specifying "url" (instead of tabId/frameId).

browser.downloads.download({
  url: ...,
  requestInitiator: { // <-- new name.
    tabId: ...,
    frameId: ...,
  },
});

What behavior should developers expect if requestInitiator is not given? IMO, we can derive the key from the activeTab or use no key here.

At the introduction of this new property, we must also account for what we want when conflicting properties are set, such as requestInitiator + incognito (private browsing mode).

Why they are conflicting? Couldn't a download request be initiated from a private browsing session?

firstPartyDomain is already a known concept in the cookies extension API, so if we are able to describe reasonable rules for how the property is used (and that this always results in the desired result), then I'd rather add the property, than to have a broken extension API for many releases (the API is functionally broken; waiting for the ideal solution to bug 1670278 may take a while).

Given that we can auto-detect the right key by using the tabId + frameId, do you still think we need to add this new property?

If we're going to proceed with a superior alternative that fully covers the use case of the new property, then no, the additional property isn't necessary.

Comment 16

[Rob Wu [:robwu]]

(In reply to Tim Huang[:timhuang] from comment #15)

My thought was that maybe we can derive the key from the currently active tab, i.e. tabTracker.activeTab. But, perhaps, this is not always the case if the download was not meant to be related to a tab.

We cannot make the assumption that a download is related to the current tab. So we cannot use activeTab (as you're suggesting below).

What behavior should developers expect if requestInitiator is not given? IMO, we can derive the key from the activeTab or use no key here.

Whatever that makes the most sense for the common case.
I guess treating it as a first-party request? Maybe even looking up likely candidates and choosing the first one that has been cached? I'm open to suggestions.

At the introduction of this new property, we must also account for what we want when conflicting properties are set, such as requestInitiator + incognito (private browsing mode).

Why they are conflicting? Couldn't a download request be initiated from a private browsing session?

If we expect the download to infer all related origin attributes from requestInitiator, then there is a conflict if the tab is non-private while incognito is set. This conflict can easily be resolved, e.g. by prioritizing one over another or by rejecting the API call together. But this potential conflict should be accounted for (i.e. a design decision needs to be made).

Comment 17

[Rob Wu [:robwu]]

Tim, in the interest of resolving this bug sooner, I forked the task of introducing a new API to bug 1698863. That new bug captures the discussion that I have had with my team.

This bug's primary goal is to resolve the regression, by automatically selecting a reasonable partition for a browser.downloads.download() API call.

Comment 18

[Tim Huang[:timhuang]]

I see.

So, I guess we should treat the request as the first-party in this bug, meaning that use the URL of the download as the partitionKey.

Do you think this makes sense?

Comment 19

[Tim Huang[:timhuang]]

But I am not sure if this can resolve this issue because the key might be different from the first party where the resources were cached.

Comment 20

[Rob Wu [:robwu]]

While this may not work for everything, it will work for the common case. Better heuristics are welcome if you can think of it, but otherwise this is as good as we can get.

If you want to try harder, you can try to look into the possibility of querying the cache for an available enrry before falling back to the first party. But just initiating a first party request is simpler and more predictable, so I'd go with that.

Comment 22

[Tim Huang[:timhuang]]

Attachment: Bug 1691907 - Part 1: Make the DownloadSource to be aware of the CookieJarSettings. r?mak

This patch makes the DownloadSource to be allowed to set the
cookieJarSettings that will be set to the channel for downloading the
resource.

Comment 23

[Tim Huang[:timhuang]]

Attachment: Bug 1691907 - Part 2: Add a method `initWithURI` to nsICookieJarSettings. r?dimi

This patch adds a method initwithURI to nsICookieJarSetting in order
to allow JS code to be able to set the paritionKey of the
CookieJarSettings.

This is needed for web extension for creating and setting the
cookieJarSettings for the download resource.

Depends on D109758

Comment 24

[Tim Huang[:timhuang]]

Attachment: Bug 1691907 - Part 3: Set the cookieJarSettings for Web Extension downloads.download(). r?robwu

This patch makes the downloads.download() to create the
cookieJarSettings and set it to the download source, so that the
downloading channel will get the partitionKey from the
cookieJarSettings. This will use the download url as the partitionKey,
meaning that we treat the download as a first-party loading.

Depends on D109759

Comment 25

[Tim Huang[:timhuang]]

Attachment: Bug 1691907 - Part 4: Add a test to ensure the Web extension downloads API will have the correct partitionKey. r?robwu

This patch adds a test to ensure downloads.download() will set the
partitionKey for the download channel.

Depends on D109760

Comment 26

[Tim Huang[:timhuang]]

Attachment: Bug 1691907 - Part 5: Add a test for Downloads API. r?mak

This patch adds a new test for making sure the option.cookieJarSettings
works as expected for Downloads API. We should be able to get the
partitionKey from the download channel which matches the key that was
set from the option.cookieJarSettings.

Depends on D109761

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6d3b522f03d7
Part 1: Make the DownloadSource to be aware of the CookieJarSettings. r=mak
https://hg.mozilla.org/integration/autoland/rev/379fd9a10dd8
Part 2: Add a method `initWithURI` to nsICookieJarSettings. r=dimi,robwu
https://hg.mozilla.org/integration/autoland/rev/f614295240dd
Part 3: Set the cookieJarSettings for Web Extension downloads.download(). r=robwu
https://hg.mozilla.org/integration/autoland/rev/a455ac90f716
Part 4: Add a test to ensure the Web extension downloads API will have the correct partitionKey. r=robwu
https://hg.mozilla.org/integration/autoland/rev/a073c7b0d5c0
Part 5: Add a test for Downloads API. r=mak

Comment 28

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/6d3b522f03d7
https://hg.mozilla.org/mozilla-central/rev/379fd9a10dd8
https://hg.mozilla.org/mozilla-central/rev/f614295240dd
https://hg.mozilla.org/mozilla-central/rev/a455ac90f716
https://hg.mozilla.org/mozilla-central/rev/a073c7b0d5c0

Comment 29

[u669213]

Sorry but this is not fixed. Can somebody reopen this? I tested both that what first post said, and my bug is also still existing https://bugzilla.mozilla.org/show_bug.cgi?id=1687569

Comment 30

[Tim Huang[:timhuang]]

I think the fix here only covers certain use cases. A more general fix will be in Bug 1698863.