Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Retrying Save As Web Page, Complete does not retry all files

  • 3 பதிலளிப்புகள்
  • 1 இந்த பிரச்சனை உள்ளது
  • 19 views
  • Last reply by Jidis Safi

Using 118.0.1 (64-bit) under Linux Mint 21.2.

Apparent bug: Retrying failed "Web Page, Complete" case of "Save Page As..." does not retry downloading files.

  1. Observed behavior:

1. With the extension "DuckDuckGo Privacy Essentials" enabled, typically if I do "Save Page As..." and choose "Web Page, Complete", then one or more files in the resulting "... Files" folder is missing compared to if the extension is disabled. This is probably as it should be. But...

2. In the downloads dropdown the download is shown as "failed". This is arguably as it should be, though the lack of information as to exactly which file download failed is unhelpful. Or arguably it is not as it should be, since from the point of the privacy extension user the download did not fail, it succeeded completely. But...

3. ***If I then click on the retry icon, it re-downloads *only the HTML*, not the files folder, and reports success.***

  1. Expected behavior:

If a "Save As..." "Web Page, Complete" fails, then retry should attempt to re-download all the files, or at least all the ones thought to have failed.

Using 118.0.1 (64-bit) under Linux Mint 21.2. Apparent bug: Retrying failed "Web Page, Complete" case of "Save Page As..." does not retry downloading files. # Observed behavior: 1. With the extension "DuckDuckGo Privacy Essentials" enabled, typically if I do "Save Page As..." and choose "Web Page, Complete", then one or more files in the resulting "... Files" folder is missing compared to if the extension is disabled. This is probably as it should be. But... 2. In the downloads dropdown the download is shown as "failed". This is arguably as it should be, though the lack of information as to exactly which file download failed is unhelpful. Or arguably it is not as it should be, since from the point of the privacy extension user the download did not fail, it succeeded completely. But... 3. ***If I then click on the retry icon, it re-downloads *only the HTML*, not the files folder, and reports success.*** # Expected behavior: If a "Save As..." "Web Page, Complete" fails, then retry should attempt to re-download all the files, or at least all the ones thought to have failed.

தீர்வு தேர்ந்தெடுக்கப்பட்டது

Yes I did. Why is this link not on the Firefox support page? I looked for it but could find nothing but a link to this community.

Read this answer in context 👍 0

All Replies (3)

தீர்வு தேர்ந்தெடுக்கப்பட்டது

Yes I did. Why is this link not on the Firefox support page? I looked for it but could find nothing but a link to this community.

This looks like the most recent, non-archived report on the same issue I've had for ages, and I'm actually on Windows 7 64-bit (currently using Firefox ESR Version 115.2.0). If it helps any, I checked a few things just now after reading suggestions in some of the other posts on it.

- Path length seems to have no connection. I stripped the saved .html file/folder name down to a single word, saved in the root of my storage drive, and it still allegedly fails.

- On the couple checks I just did, the actual batch of files in the saved "_files" folder of the failed save checksums OK against those of a successful save after using the retry button. I thought that in the past, it was saving an incomplete batch of files, where most of the images weren't saved, but I guess that's not always the case.

- The actual .html file, on the other hand, did not match on checksums, so maybe the failure is in that file rather than the corresponding folder, unless the file content normally changes due to dynamic ads or something else.

It's not 100% consistent, as some "web page, complete" saves go through with no problem. It also might be worth noting that I seem to be one of the few who run with Windows *not* set to hide all the file extensions. I think that's caused some related issues in the past that none of the people running on the default seemed to have.

Maybe something in there could help narrow it down. - Thanks!