1658673 - Downloading images from certain sites using the extension "browser.downloads.download" api fails with error "NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.responseStatus]"

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, defect)

Description

[Christopher]

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

Steps to reproduce:

In the context of an extension with the downloads permission, attempt to download an image from twitter.com using the browser.downloads.download api, for example

browser.downloads.download({url: "https://pbs.twimg.com/media/Ee35vTLUYAAMUH8?format=jpg&name=orig"})

Did not occur on Firefox Nightly 80 and below, but does occur on Firefox Nightly 81. Currently testing on Firefox Nightly 81.0a1 (2020-08-10) (64-bit), on Arch Linux. I have only encountered this issue while attempting to download images from Twitter (or rather their image cdn, pbs.twimg.com), and cannot reproduce it when attempting to download from other websites. I have attempted it in a fresh profile with no change in results.

Actual results:

the downloads pane lists the download as failed, and the following errors are printed in the browser console

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIUrlClassifierBlockedChannel.topLevelUrl] trackingProtection.js:41
    observe jar:file:///opt/firefox-nightly/browser/features/[e-mail]!/experiment-apis/trackingProtection.js:41
NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.responseStatus] DownloadCore.jsm:2092
    onStartRequest resource://gre/modules/DownloadCore.jsm:2092
    <anonymous> self-hosted:1161

Expected results:

Download should complete successfully as is the case when using right click, save image as.

Comment 1

[Christopher]

My apologies, the bug in question started with Firefox Nightly 80, not 81 as stated above, and did not occur in Firefox Nightly 79 and below.

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Alex Cornestean]

Hello,

I haven’t managed to reproduce the issue on the latest Nightly (81.0a1/20200813092915) under Windows 10 Pro 64-bit nor on Ubuntu 16.04 LTS.

I’ve tried using several image download add-ons listed on AMO such as:

• Download All Images (https://addons.mozilla.org/en-US/firefox/addon/save-all-images-webextension/?src=search)
• Image Downloader (https://addons.mozilla.org/en-US/firefox/addon/image-downloader-addon/?src=search)
• Double-click Image Downloader (https://addons.mozilla.org/en-US/firefox/addon/double-click-image-download/?src=search)
• Image Downloader (https://addons.mozilla.org/en-US/firefox/addon/download-all-images-button/?src=search)
• Easy Image Downloader (https://addons.mozilla.org/en-US/firefox/addon/easy-image-downloader/?src=search)

Note: I have targeted the image (https://pbs.twimg.com/media/Ee35vTLUYAAMUH8?format=jpg&name=orig) mentioned in the report directly and also random images from different twitter pages. The images download just fine and the mentioned errors are not displayed.

Could you please provide the extension you were using when the issue occurred, in case the so far tested add-ons are not appropriate for this bug. Thank you!

Comment 4

[Rob Wu [:robwu]]

Tom, I think that you may be interested in the first error, as that error can only start to happen since bug 1637329.

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIUrlClassifierBlockedChannel.topLevelUrl] trackingProtection.js:41
observe jar:file:///opt/firefox-nightly/browser/features/[e-mail]!/experiment-apis/trackingProtection.js:41

Cristopher, could you elaborate on the reproduction steps?
Are you signed in? Did you change any tracking protection settings?
What does manifest.json look like? If it lacks host permissions, could you check whether you may be affected by bug 1655190?

Reportedly there may still be an issue with downloads.download on Twitter at bug 1621249 (comment 4 for STR and comment 10 to mention potentially broken behavior on Twitter). Can you check those detailed reproduction steps, and confirm whether it matches your issue?

Comment 5

[Christopher]

I've been using the extension Save Image In Folder, however there was a crucial error in my clean profile testing. I signed into sync on the profile and disabled the other add-ons. A truly clean profile with only that add-on enabled works. However this lead me to figure out the root cause is Strict mode Enhanced Tracker Protection being enabled. With Standard mode this issue is not seen. Disabling Enhanced Tracker Protection on twitter.com and pbs.twimg.com with Strict mode enabled over all does not change the behavior described in this bug in a new profile with only Save Image In Folder installed. My apologies for the shoddy testing methodology.

Comment 6

[Victor Carciu]

Using the info from comment #5 , I was able to reproduce the issue with the same error like the one from bug description.

I ran a bisection with the following results:

2020-08-17T20:43:21: DEBUG : Found commit message:
Bug 1437626 - P5. Only call ShouldEnableClassifier for protection features. r=baku

ShouldEnableClassifier checks two things:

1. If AddOn can load the channel
2. If the classified channel is top-level.

For the first point, we added the check in Bug 1308640, and I think the
idea is only for tracking protection to not block channels when
extensions have permission on the channels' domain.
For annotation features, we should always annotate a channel regardless of whether
it is controlled by extensions (also for ETP).

And since we use first-party classification flag in channels, so we
should also annotate channel no matter it is top-level, first-party or
third-party.

So this patch removes calling ShouldEnableClassifier in annotation
features and also rename ShouldEnableClassifier to
ShouldEnableProtectionForChannel to make the idea more clear.

Differential Revision: https://phabricator.services.mozilla.com/D82504

2020-08-17T20:43:21: DEBUG : Did not find a branch, checking all integration branches
2020-08-17T20:43:21: INFO : The bisection is done.
2020-08-17T20:43:21: INFO : Stopped

Pushlog_url : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=925c602db317d006781e7980f99d22b39a2c4b4f&tochange=9c99b566c1fe17cc7cfde9eb09798bb788dbb687

Comment 7

[Rob Wu [:robwu]]

Thanks for the regression range.

Since this regression is currently on Beta only, I'm going to try and get a patch uplifted.
We were already planning to land a simple patch to improve the behavior anyway, but this regression shows that we need to prioritize the fix in bug 1655190.

Comment 8

[Rob Wu [:robwu]]

I am able to get sameSite=none and sameSite=Lax working with the "simple" fix described in bug 1655190, but not sameSite=Strict.
I think that the absence of sameSite=strict cookies may have the same root cause as bug 1659578, which is likely not trivial.

So I'm going to attach a patch with the simple fix here (+request uplift), and keep bug 1655190 open for the sameSite=strict case.

Comment 9

[Rob Wu [:robwu]]

Actually, I found a way. I'm going to attach it to the bug 1655190.

Comment 10

[Rob Wu [:robwu]]

I investigated the unrelated error and filed a new bug at bug 1660108.

bug 1655190 has been resolved and has a pending uplift request to deal with this regression.

Comment 11

[Rob Wu [:robwu]]

Uplifted to 80.0.1 in bug 1655190.