Bugzilla

One case where the current behavior is useful is if the PDF display fails because of a CORS error. If it's a valid PDF you can download it and view it in another viewer (in the Firefox case, it will render in the browser instead by default). So if we get a CORS error it might make sense to tell the user that PDFjs didn't have permission and offer to try to open it in a new tab. But not through the "download" button, because the CORS error might be hiding a non-PDF.

But this is clearly not intentional behavior: if you specify `file=https://www.evil.site` with the scheme we don't try to do the download because we know the document had an error. We only try to do the download if we end up having to resolve the relative URL. Strangely, download_manager.js is resolving it against an explicit baseURL of "http://example.com" (note: insecure) instead of something sensible like the viewer site. Not that that would make a difference here. It creates a  link with a `download` attribute and clicks it, but we don't always honor that attribute.

One case where the current behavior is useful is if the PDF display fails because of a CORS error. If it's a valid PDF you can download it and view it in another viewer (in the Firefox case, it will render in the browser instead by default). So if we get a CORS error it might make sense to tell the user that PDFjs didn't have permission and offer to try to open it in a new tab. But not through the "download" button, because the CORS error might be hiding a non-PDF.

[deleted incorrect stuff about only relative URLs.]

Separate issue, but for some strange reason download_manager.js resolves relative URLs against an explicit baseURL of "http://example.com" (note: insecure) instead of something sensible like the viewer site. This will cause browsers to use insecure connections, and depending on the site the insecure http: version of a resource could be different (or not found) than the https: version the relative URL was looking at. Doesn't change anything wrt this reporter's bug, just noting it.

We then a  link with a `download` attribute and click it, but we don't always honor that attribute if the fetched content-type is one we've decided the browser knows how to handle (like html)