User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Hi guys.

First time filing a bug report so hopefully what I've got here is useful and helpful. It's a repeatable bug, and works fine in other browsers so that's a good start I guess. This bug has persisted for some time, and since it hasn't yet been resolved I thought it was time I filed a bug report.

The issue is I am unable to download .txt files from this website, but I'm pretty sure it affects other websites as well, this is just one I access frequently:

https://support.magicard.com/solution/enduro-firmware/

The binary file download links work fine, and I can view the .txt document in preview mode just fine but I'm unable to save it at all, either from the context menu or from the save as menu when previewing.

Actual results:

If I try from the context menu "Save Link As" option Firefox just immediately says "The download cannot be saved because an unknown error occurred. Please try again."

Trying from the "Save As" menu when previewing just results in a failed download in the download window.

Expected results:

Expected behavior is obviously that the .txt file successfully downloads.

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

Please disable add-ons and try again. In my case, uMatrix blocked the access "rackcdn.com" from "support.magicard.com".

That said, if some extensions blocked the "Save Link As" operation, the error message should inform users. The current error message is too generic. Since DevTools NetMonitor shows the blocker, the information should be available (maybe here).

I do indeed use uMatrix but I wouldn't have expected it to interfere with simply downloading a .txt file of all things.

I just tested on another PC without uMatrix and it indeed does work. How frustrating.

I never would have suspected uMatrix was the issue.

On Chrome, "Save Link As" requests do not belong to any tabs. uMatrix will report them as "behind-the-scene" requests and allow them by default. But we can't do the same due to container tabs (see bug 1398229).

We can try and improve UI so "blame" for the failure is correctly attributed, so morphing for that.

Also, Shaun, it's probably worth reporting this to uMatrix who may be able to fix this specific issue you're seeing.

In the general case though, from Firefox's UI perspective, ideally we'd provide an option to bypass the add-on blocking the request. The issue with that is that because each add-on will have its own way of configuring it, the only "OK but I want to download the file" UI option we could obviously provide (I think) is to disable the add-on completely and then trip the download, which is likely not the ideal solution. Rob, is there some way that we could re-try the request with some kind of flag saying "bypass webextensions", or even "bypass [only] webextension X" ? Obviously the latter might then fail with a block from a different webextension (sigh) but by that point we must be in the diminishing returns territory...

I think that we can/should show that a request was modified by an extension.

Offering the ability to retry a request without an add-on is complicated, and I'm not sure if it is an effective way against this kind of issue. Users can retry in a private browsing window (where extensions are disabled unless opted in).

https://hg.mozilla.org/mozilla-central/rev/7c185cdc3093