Bugzilla

(In reply to :Gijs (he/him) from comment #7)
> When the download attribute applies, it is treated the same way as a `Content-Disposition: attachment` header sent by the server. As I noted before, per bug 453455, we think the user's preferences should win over what the server says - irrespective of whether the user has indicated they want the PDFs to open in an external app (Acrobat or w/e), automatically save to disk, or opening in Firefox.

In general I agree that for now the current behavior is ok, and we should continue monitoring feedback.
There's just a couple concerns that have been rised, and I can sympathize with some of it:
1. not coherent with other browsers. Of course the user doesn't know what happens on that site, since it's server side, unless they commonly use that side in another browser. Then migrating to Firefox would break expectations on that site.
2. The part about respecting the user's will won't work when the server uses octect-stream, that's not something you can set a preference for. Thus we're not providing a predictable experience anyway, the pdf may still either be downloaded or shown without the user knowing in advance. We just moved the needle a little bit more towards showing.

That said, I don't think both are critical concerns, there's workarounds or alternative workflows for most of this, like you said the pdf reader allows to download.

(In reply to :Gijs (he/him) from comment #7)
> When the download attribute applies, it is treated the same way as a `Content-Disposition: attachment` header sent by the server. As I noted before, per bug 453455, we think the user's preferences should win over what the server says - irrespective of whether the user has indicated they want the PDFs to open in an external app (Acrobat or w/e), automatically save to disk, or opening in Firefox.

In general I agree that for now the current behavior is ok, and we should continue monitoring feedback.
There's just a couple concerns that have been rised, and I can sympathize with some of it:
1. not coherent with other browsers. Of course the user doesn't know what happens on that site, since it's server side, unless they commonly use that site in another browser. Then migrating to Firefox would break expectations on that site.
2. The part about respecting the user's will won't work when the server uses octect-stream, that's not something you can set a preference for. Thus we're not providing a predictable experience anyway, the pdf may still either be downloaded or shown without the user knowing in advance. We just moved the needle a little bit more towards showing.

That said, I don't think both are critical concerns, there's workarounds or alternative workflows for most of this, like you said the pdf reader allows to download.