Bugzilla

(In reply to Whymarrh Whitby from comment #57)
> (In reply to :Gijs (he/him) from comment #55)
> > Whymarrh, could you confirm that this fix addresses the original issue for you with Firefox 101, which is currently available through beta? ( https://beta.mozilla.org/ )
> 
> Tested in Version 102.0a1 (Build ID 20220505113034) and the behaviour is now different and possibly better, but in my opinion, still not correct. The `download` attribute isn't respected, which doesn't make sense to me as a web author or as an end-user when the link/button text says "Download."

Thank you for checking. As previously discussed (e.g. comment 15), I think we differ in our sense of expectation here. `Content-disposition: attachment` and (same-origin) `<a download>` are supposed to be treated the same, and our experience (through many duplicates of the bug mentioned there, but also e.g. bug 1655974) is that users do not understand why their configuration (for PDFs or other files) would apply to *some* downloads (ones without `Content-Disposition: attachment`), but not *other* downloads - it makes the behaviour unpredictable, and moves control from the user to the website. As a result, we're specifically trying *not* to distinguish those cases, both for PDFs and for other filetypes. While I agree that that has the potential to be confusing given website labelling, I would argue that that confusion is unavoidable, as the alternative (treating some files differently from other files) is **also** confusing, and at this point in time we've erred on the side of consistency wrt user expectations/settings, and prioritizing user preferences over website preferences. My understanding is that other browsers do the same thing 

The point of the work in this bug was specifically to address the issue around website contents being replaced unexpectedly, and it sounds like that was successful.

(In reply to rchavik from comment #56)
> - The default filename is lost and replaced with `document.pdf` as mentioned above

Thanks, the filename fix landed after the beta branch date and is currently only available on nightly. We could uplift to beta but there's a comment in bug 1767321 suggesting that that was only partially resolved (but the broken testcase involves having an account with a Canadian ISP, so isn't super easy for us to reproduce), so it would be useful if you could check if it works on nightly with your testcases, esp. if those are publicly accessible, and comment there if you are also still seeing issues.

(In reply to Whymarrh Whitby from comment #57)
> (In reply to :Gijs (he/him) from comment #55)
> > Whymarrh, could you confirm that this fix addresses the original issue for you with Firefox 101, which is currently available through beta? ( https://beta.mozilla.org/ )
> 
> Tested in Version 102.0a1 (Build ID 20220505113034) and the behaviour is now different and possibly better, but in my opinion, still not correct. The `download` attribute isn't respected, which doesn't make sense to me as a web author or as an end-user when the link/button text says "Download."

Thank you for checking. As previously discussed (e.g. comment 15), I think we differ in our sense of expectation here. `Content-disposition: attachment` and (same-origin) `<a download>` are supposed to be treated the same, and our experience (through many duplicates of the bug mentioned there, but also e.g. bug 1655974) is that users do not understand why their configuration (for PDFs or other files) would apply to *some* downloads (ones without `Content-Disposition: attachment`), but not *other* downloads - it makes the behaviour unpredictable, and moves control from the user to the website. As a result, we're specifically trying *not* to distinguish those cases, both for PDFs and for other filetypes. While I agree that that has the potential to be confusing given website labelling, I would argue that that confusion is unavoidable, as the alternative (treating some files differently from other files) is **also** confusing, and at this point in time we've erred on the side of consistency wrt user expectations/settings, and prioritizing user preferences over website preferences.

The point of the work in this bug was specifically to address the issue around website contents being replaced unexpectedly, and it sounds like that was successful.

(In reply to rchavik from comment #56)
> - The default filename is lost and replaced with `document.pdf` as mentioned above

Thanks, the filename fix landed after the beta branch date and is currently only available on nightly. We could uplift to beta but there's a comment in bug 1767321 suggesting that that was only partially resolved (but the broken testcase involves having an account with a Canadian ISP, so isn't super easy for us to reproduce), so it would be useful if you could check if it works on nightly with your testcases, esp. if those are publicly accessible, and comment there if you are also still seeing issues.