(In reply to Magnus Melin [:mkmelin] from comment #28)
> We get no window interface, so this throws: https://searchfox.org/mozilla-central/rev/bf8d5de8528036c09590009720bc172882845b80/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#140
> 
> Adding ` && alwaysAskBeforeHandling` to this condition fixes things (apart from still getting js errors in console, and the what-to-do dialog saying the pdf is an HTML document).
> https://searchfox.org/mozilla-central/rev/a2c26b9b49a521f4be39559ca1ca9c345a237c70/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1145
> 
> Likewise a `getDOMWindow(aChannel, triggeringPrincipal);` call there, causing us to bail, will also fix it. 
> 
> Bug 1726501 seems very related.
> :Gijs, you worked on this for Firefox. Thoughts?

I don't really understand the context here, even though I use thunderbird. Let me try to provide some context around PDF.js and then maybe we can figure this out.

The PDF.js streamconverter is there so that when a docshell/browsingcontext navigates to a PDF, it "converts" (via the stream converter interfaces/logic) to HTML, so that the docshell ends up loading the pdfjs viewer which then displays the PDF via its HTML window. Other stream converters include the "unstyled XML" processor and the JSON viewer (in devtools/client/jsonview/converter-child.js).

So it providing a replacement content type of `text/html` is intentional, if we're going to use PDF.js to display the file internally.

I don't *think* the stream converter should be used for channels where there is no DOM window. Checking for a non-null `aChannel?.loadInfo.targetBrowsingContext` in `getConvertedType` would be a good start to enforce that. I assume that in bug 1734428 / comment 3, the way this was worked around was ensuring that PDFs get loaded "into something" as opposed to just opening a file channel and hoping for the best.

Note that you can't avoid showing an error in the console here (or at least, I'm not aware of a way of doing so) - the documented way for a stream converter to indicate it cannot handle a channel is to return non-NS_OK, which then produces an error in the error console. You can control what the message is shown, though (see e.g. https://searchfox.org/mozilla-central/rev/a2c26b9b49a521f4be39559ca1ca9c345a237c70/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1123-1126 ).

The code in the stream converter was primarily written when this all still lived in `browser/` and so it assumes a number of things, such as:

- system principal is used as a proxy for the user explicitly using their OS filepicker to open with [the running application], in which case it makes no sense to ask what to do, we should just open with pdf.js (unless that is disabled), not ask the user a second time how they want to handle the file. This is true in Firefox; it may not be true in Thunderbird. I'm not sure how to deal with this discrepancy in the relevant code. Perhaps a pref that is set differently; using `AppConstants` or otherwise hardcoding a behaviour for either "everything but Firefox" or "everything but Thunderbird" feels wrong.
- `file:///` principal for `file:///` PDFs with "always ask before handling" is forced into PDF.js, because the "open with Firefox/Thunderbird" option in the unknownContentType dialog doesn't work in this situation (cf. bug 1680147). I'm not sure if this comes into play here or not, because I'm not sure what principal tb passes when opening the channel.

Hopefully that helps?