1343466 - Downloaded file always marked as "Failed" in "Downloads" and in downloads notification panel with yellow dot on some websites with content blocker extension

Status: VERIFIED DUPLICATE of bug 1445211

(WebExtensions :: Request Handling, defect)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

1. Open this URL - https://web.archive.org/web/20160730121254/https://gribble.org/lcdfix/
2. Press right mouse button somewhere in the page to get context menu
3. Press "Save Page As..."
4. Choose "Web Page, complete (*.htm; *.html)" option if it's not already chosen
5. Press "Save" button
6. and see that some files are downloaded, maybe even all,
but in "Downloads" button there is yellow dot
and in Downloads notification panel and in "Downloads" (Ctrl+J) downloaded file is marked as "Failed"

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

+ uBlock Orgin extension is needed to be able to reproduce it

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

+ additional "Fanboy’s Enhanced Tracking List" is needed to be able to reproduce it

Comment 3

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Looks like the settings file was in some way broken. Removing extension and setting the same preferences fixed the problem.

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #3)
> extension settings file

Comment 5

[gwarser]

I can reproduce this in current stable Build ID 20181206201918 and Nightly Build ID 20181216095236 with Adblock Plus 3.4.2 or uBlock Origin 1.17.4 but not with Adblock for Firefox 3.23.1

One small difference - "dot" on "Downloads" button sometimes blinks only once and disappears, but status still shows "Failed"

Other people also have this problem https://www.reddit.com/r/uBlockOrigin/comments/9wnlb4/saving_web_pages_fails_when_ublock_origin_is/

Comment 6

[gwarser]

I see current platform is set to Windows 7, on reddit people say about win 10 and 7 but I'm on Linux Manjaro.

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Reopening per Comment #5 and changing "Platform:" from "Windows 7" to "All".

@ gwarser - Thank you very much for information and needinfo!
If you could, please post also reliable STR. Thank you very much in advance!

Comment 8

[gwarser]

Thank you for reopening.


> If you could, please post also reliable STR. Thank you very much in advance!


STR from bug description is fine. I tested in fresh profiles with freshly installed add-ons.

Comment 9

[Marco Bonardo [:mak]]

Sounds like an edge case

Comment 10

[zivontsis]

This bug just caused me to lose a SUBSTANTIAL amount of data which I cannot get back.

I had just saved a number of pages which I only had limited time access to. They appeared in the "failed" state as described here, but I didn't give it any thought because I thought this was just a visual bug. The HTML files were still being saved into my downloads directory as expected, even though they appeared as "failed", so I continued saving the pages.

However, after clearing my downloads pane, Firefox erased all the HTML files.

This was quite an unexpected behaviour for me and I am now no longer able to access those pages. The data is gone forever.

Please, at the very least, change this behaviour of deleting the partially downloaded files when the downloads pane is cleared in the case of a partially failed page save. I'm not too concerned about the erroneous appearance of a yellow dot, but this possibility for data loss IMO makes this bug much more serious.

Comment 11

[zivontsis]

I think my issue might be more related to bug #964213 although this bug is related as well. I will reproduce my comments there.

Comment 13

[James [:FormularSumo]]

I have had the same thing happen to me recently, all my downloads are marked as failed, and most of them are actually failed and only partially download. I'm using Firefox Beta 70.0b12 on windows 10 64bit.

Comment 15

[Shane Caraveo (:mixedpuppy)]

Using the STR from comment 0, I can reproduce using web.archive.org. However, in a profile with no addons at all, and our internal tracking protection turned off, I can also reproduce (you can see in dev tools that there are some 404s, and there is a request that never completes). The issue is that some items in the page are not downloaded, thus as mentioned in comment 11, the problem with that particular page looks like bug 964213.

If I go to a page that loads all its included resources correctly, my download succeeds.

A simpler STR is to use cnn.com as the page.

With uBlock origin installed and tracking protection with default settings, uBlock blocks 36 items (for me). If I save that page, the downloads panel shows the download failed.

If I turn off uBlock, but leave default tracking protection settings, the download succeeds.

If I turn off uBlock and tracking protection, the download succeeds.

uBlock is probably using a webRequest handler to cancel some requests. The downloads manager has no indication that is on purpose, it only sees the request is canceled, thus it cannot complete a download.

In no case that I tested did I have any data loss as suggested in comment 10.

This isn't really an extension bug, or a downloads manager bug, both are working as designed. But the interaction between the two is not right.

It might be good for there to be a way for the downloads manager to know that some resources were blocked (by TP, or an addon) and that it could not download all resources, but that those allowed are complete. Some input from someone familiar with the downloads manager might be helpful, including how it seems to be fine with TP blocking some resources.

In any case, this is a dup.

Comment 16

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Thank you for your input and detailed explanation.
P.S. More like bug #1445211 is duplicate of this one, as this one is older and has more information now.

Comment 18

[Shane Caraveo (:mixedpuppy)]

I duped in the direction I wanted because there is discussion happening there that I preferred to preserve. Age of bug doesn't matter here.

Comment 19

[Shane Caraveo (:mixedpuppy)]

Please do not re-triage bugs the team triages without asking first if you disagree. Sometimes we do have reasons.

Comment 20

[Matthew Woehlke]

I duped in the direction I wanted because there is discussion happening there that I preferred to preserve.

...but if that's your explanation, I'm not sure I agree that this is a duplicate. There is a lot of talk about "host blocking" there that doesn't seem to apply here at all. The direction of this report, prior to being closed as a duplicate, was that we should provide better tools to extensions to understand when a network request is triggered by the user asking to directly download something. That seems worth preserving, and I am not convinced we don't lose that by making this a duplicate of #1445211.

(Actually, it occurs to me that an alternate fix for this issue, which would have the bonus of not requiring any changes to extensions, would be to make 'save image' trigger an image request rather than an "other" request. Admittedly, that probably isn't enough for a general fix, but it does happen to solve my particular use case... Although another alternative would be to not re-download the image in the first place.)

Comment 21

[Matthew Woehlke]

Er... sorry, the above actually refers to bug #1587208 which was closed as a duplicate of this... which was reasonable before this was closed as a duplicate of bug #1445211.

Comment 22

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

My bad, I'm very sorry about fuss I caused!