Closed Bug 1691907 Opened 6 months ago Closed 4 months ago

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

Categories

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

Firefox 85
defect

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed

People

(Reporter: ke5trel, Assigned: timhuang)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(5 files)

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.

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

Flags: needinfo?(jstutte)

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

Flags: needinfo?(tihuang)
Flags: needinfo?(jstutte)
Flags: needinfo?(amarchesini)

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.

Flags: needinfo?(tihuang)
Flags: needinfo?(amarchesini)
Severity: -- → S3
Priority: -- → P2

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

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?

Flags: needinfo?(rob)

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.

Blocks: 1695682
Flags: needinfo?(rob) → needinfo?(tihuang)
See Also: → 1669716, 1670278, 1689752

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

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

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

Flags: needinfo?(tihuang)

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

Flags: needinfo?(rob)

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

Flags: needinfo?(rob)

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.

Flags: needinfo?(tihuang)

(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?

Flags: needinfo?(tihuang) → needinfo?(rob)
Assignee: nobody → tihuang
Status: NEW → ASSIGNED

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

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

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

Flags: needinfo?(rob)
See Also: → 1698863

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.

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?

Flags: needinfo?(rob)

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.

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.

Flags: needinfo?(rob)
Blocks: 1687569
Duplicate of this bug: 1687569

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

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

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

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

Depends on D109760

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

Pushed by tihuang@mozilla.com:
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
Depends on: 1702348

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

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

Duplicate of this bug: 1689752
See Also: → 1720360
You need to log in before you can comment on or make changes to this bug.