[upstream] In Compose window, if a PDf is joined and clicked to open, Thunderbird launches Firefox instead of Evince

[Xavier Guillot]

In Thunderbird on Ubuntu Gnome, I set Evince as default program to open pdf files from Thunderbird.

In received messages, and those saved on "Sent" folder, it works perfectly.

But in the "Compose" window: if I add a pdf file to the message, and double-click on it to open and verify it, Thunderbird always uses Firefox to show it.

In case Firefox is not installed (has been removed), I have an error message telling there is not associated application for pdf files and to go to Preferences - where Evince is already and still defined as default.

It happens since many months and bug is still present in Thunderbird 102 / Ubuntu 22.10 beta.

It's not the same as bug 234349 as here, it's not an URL file but directly a pdf joined in a mail.

[9-henry (9-henry)]

## Steps to Reproduce

Compose or Edit a message with a pdf attachment.

Open the pdf attachment (through double click or context menu).

## Result

Get popup message

```
You have chosen to open:
    <file>.pdf
    which is: HTML document
```

So the type is HTML, which means you'll likely get a recommendation to open in a browser, rather than the default pdf reader.

Also get the printed error message

```
JavaScript error: resource://pdf.js/PdfStreamConverter.jsm, line 140: TypeError: can't access property "getInterface", requestor is null
```

*Note: opening attachments when viewing a message (not composition), in either a tab or a separate window works fine.*

## Expected

The file to be treated as a PDF and no error message.

## Origin?

Looking in `PdfStreamConverter.jsm`, the error is from `getDOMWindow` (https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#136), which is called by `proxy.onStopRequest`. The problem seems to be that both `aChannel.notificationCallbacks` and `aChannel.loadGroup.notificationCallbacks` are `null`.

*Note: opening an attachment in a viewed message (not composing), does not seem to pass through the same code.*

On the the thunderbird side, I've tracked down the trigger for the error to `openURI` in `MsgComposeCommands.js` (https://searchfox.org/comm-central/rev/9bc3ba1480090c4e89d5152e458f19c79b3d6ac4/mail/components/compose/content/MsgComposeCommands.js#7171).

I couldn't really pinpoint the origin much beyond this because the code is passing through interfaces (and probably between c++ and javascript), and I'm not familiar enough to navigate this.

#### Why is it treated as HTML instead?

I think the reason the document is treated as as HTML is a side effect of the JavaScript error. Also in `PdfStreamConverter.jsm`, the `onStartRequest` method changes the `contentType` from `application/pdf` to `text/html` (https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1231). Supposedly, this is done to break some loop. My guess is that it is meant to be set back to `application/pdf` during `onStopRequest`, but this method errors before it can do so.

[9-henry (9-henry)]

Note: The patch for bug 1734428 fixes the case where the user has opted to view pdfs within Thunderbird and they still have a 3pane window open.

In other cases, this bug will still be seen (error in console, and treated as a `text/html` instead of `application/pdf`). E.g. if you choose to view pdfs using your system document viewer, or if you only have open a single composition window.

[9-henry (9-henry)]

*** Bug 1737408 has been marked as a duplicate of this bug. ***

[9-henry (9-henry)]

*** Bug 1735585 has been marked as a duplicate of this bug. ***

[Mkmelin+mozilla (mkmelin+mozilla)]

*** Bug 1732045 has been marked as a duplicate of this bug. ***

[Mkmelin+mozilla (mkmelin+mozilla)]

*** Bug 1740759 has been marked as a duplicate of this bug. ***

[Wls220spring (wls220spring)]

*** Bug 1729922 has been marked as a duplicate of this bug. ***

[Anjeyelf (anjeyelf)]

Windows 10
Computer default open pdf using Adobe Acrobat

Thunderbird 91.3.0
Received email with pdf opens using Adobe Acrobat - expected so ok

TEST 1
Files & Attachments - pdf set to use Adobe Acrobat Dc default
Clear error console
Write compose window - add pdf attachment - double click to open -opens in Firefox in a new tab - not expected.
The url address shown in Firefox is:
file:///C:/Users/XXXX/Documents/ANCESTRY%20-%20Gibbons%20-%20Bell/The_Book_Gibbons_Family_Tree.pdf
Error console:
14:09:48.110
TypeError: requestor is null [Learn More] - PdfStreamConverter.jsm:140:13
getDOMWindow resource://pdf.js/PdfStreamConverter.jsm:140
onStopRequest resource://pdf.js/PdfStreamConverter.jsm:1262

Save as draft and close Write.

TEST 2
Change the Preferences
Files & Attachments - pdf set to 'Preview in Thunderbird'
Select Draft email - Edit
Write compose window - pdf attachment - same pdf as before - double click to open -opens in Firefox in a new tab - not expected.
The url address shown in Firefox is now:
file:///C:/Users/XXXX/AppData/Local/Temp/nsmail.pdf

error console repeats same error:
14:26:25.703 TypeError: requestor is null [Learn More]- PdfStreamConverter.jsm:140:13
getDOMWindow resource://pdf.js/PdfStreamConverter.jsm:140
onStopRequest resource://pdf.js/PdfStreamConverter.jsm:1262

Note: 'Learn More' is a link to this:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Unexpected_type

TEST 3
Tested with Write compose as Plain Text and also compose HTML - no difference in result nor error message.

TEST 4
Change the Preferences
Files & Attachments - pdf set to 'Always ask'
Select Draft email - Edit
Write compose window - pdf attachment - same pdf as before - double click to open --opens in Firefox in a new tab - not expected.
SAme result in error console.

TEST 5
Change the Preferences
Files & Attachments FIREFOX HTML Document - set 'Always Ask'
Clear Error console
Select Draft email - Edit
Write compose window - pdf attachment - same pdf as before - double click to open

Window opens to ask what to do - Open with - default is Firefox - so I change this to Adobe Acrobat and selected checkbox to always remember.
FRom now onwards Write compose window pdf attachment is opening in Adobe Acrobat
But this now means preferences are set up to open HTML in Adobe Acrobat which is not desirable.
Error console still producing same error.

We are getting reports in the Support forum of same issue or saying because the associated helper application does not exist.

[Anjeyelf (anjeyelf)]

UPDATE: PLEASE READ

In THUNDERBIRD
Change the Preferences again as i'm putting them back to where they should be.
Files & Attachments
Firefox HTML Document reset back to use 'Firefox default' as it cannot remain using the 'Adobe Acrobat'
PDF still set to use Adobe Acrobat default

In FIREFOX
Access Settings/Preferences - about:preferences
Files & Attachments
It has Portable Document - PDF to open in Firefox so set to use 'Adobe Acrobat'

Back in Thunderbird' reopen Draft - Edit - get Write compose windwo - click on attachment pdf and it is now opening in 'Adobe Acrobat'

REset Firefox settings - about:preferences
Files & Attachments
It has Portable Document - PDF - reset back to open in Firefox - (I like online pdf opening in firefox tab)

Back in new Write window - add attachment pdf - double click to open and it is now using Adobe Acrobat.
Error console still produces same error.

I'm not sure whether setting:
THUNDERBIRD - Change the Preferences
Files & Attachments
Firefox HTML Document from Firefox to Adobe Acrobat
testing opening of pdf
Then resetting it back to say Action: Firefox default
Seems to be fixing the issue

OR
whether after doing the above - I then changed the settings in Firefox -
PDF to use Adobe Acrobat
testing opening of pdf
Then resetting it back to say Action: Firefox default

But whether it was doing it in Thunderbird or a combination of both I'm now getting those attachments opening in Adobe

[Ivan-fabr (ivan-fabr)]

(In reply to Anje from comment #8)
> ...
> I'm not sure whether setting:
> THUNDERBIRD - Change the Preferences
> Files & Attachments
> Firefox HTML Document from Firefox to Adobe Acrobat
> testing opening of pdf
> Then resetting it back to say Action: Firefox default
> Seems to be fixing the issue
> ...

Thank you, Anje!
Your way worked for me! Hooray!

[Infobob (infobob)]

91.3.1 I don't use Firefox my system is Windows 10. I still can't open a pdf when composing an email to check contents. Never had that issue in prior versions.

[Wls220spring (wls220spring)]

(In reply to BOB from comment #10)
> 91.3.1 I don't use Firefox my system is Windows 10. I still can't open a pdf when composing an email to check contents. Never had that issue in prior versions.

What application do you expect it to open with?

What is your Action in General > Files & Attachments for the Portable Document Format (PDF) Content Type?

In 91.3.2 and previous 91.x.x versions, you should be repeatedly asked.

[Infobob (infobob)]

1. I expect the pdf file to open with Acrobat Reader DC just like when I receive an email with a pdf file attached.

2. Action is there is a drop down list which includes Adobe Acrobat DC as default, however, pdf document attached while composing email will only display if I set preference for Portable Document (PDF) as Preview in Thunderbird. Before 93.1.1 I was able to open an attached pdf file in an unsent email with Adobe Acrobat DC.

[9-henry (9-henry)]

(In reply to BOB from comment #10)
> 91.3.1 I don't use Firefox my system is Windows 10. I still can't open a pdf when composing an email to check contents. Never had that issue in prior versions.

The current problem is that, when opening the PDF attachment from the compose window, it is opened *as if* it is a HTML file. So whatever "Action" is set for "HTML documents" in preferences will be used.

This should be fixed in thunderbird, but if you need a work around to be able to view the pdf for the time being, go to Preferences -> General -> Files & Attachments and either:

1. If you have version 91.3.1 or later, set Content Type "PDF" to "Preview in Thunderbird" (this way of opening pdfs was fixed in bug 1734428).
2. Set Content Type "HTML document" to an application that can handle both PDF and HTML documents. A web browser can normally do so.
3. Set Content Type "HTML document" to "Always Ask". And when the asking prompt pops up you can manually *find* and select the pdf reader each time. This way if you open an actual HTML document, you can select the correct application as well. This requires more manual work to re-find the pdf reader each time, but I think this is the safer option if you don't use option 1 or 2.
4. Set Content Type "HTML document" to your preferred pdf reader. But I would **not** recommend this because this will mean you would fail to open *actual* HTML documents (thunderbird will attempt to open them in your pdf reader, which will likely not handle HTML). But even if you never open HTML documents at the moment, when you eventually get one (e.g. as an attachment in your inbox) you'll run into this problem but there's a good chance that you won't remember that you set up this work around.

NOTE as well, if you change any of these options this will also effect how you open files in other parts of thunderbird. Specifically, it will change how you open PDF or HTML attachments in your inbox, etc.

I think the work around in comment 8 is basically using Firefox as an intermediate application, with the idea that Firefox can handle both HTML and PDF, but if it receives a PDF type it can redirect to open it elsewhere. But this doesn't solve the problem in Thunderbird and requires keeping Firefox configured in this way.

[Infobob (infobob)]

Okay in my version 91.3.1 I followed your instructions in Suggestion #1 and changed the Content Type "PDF" to "Preview in Thunderbird" and now a new tab opens where I can view the contents of the attached file. It is not like before when Adobe Acrobat would bring up the document, however, at least I may view the contents of the attached document prior to sending the email.

I don't know about the other steps #2-#4 so I am not trying them.

Thank you.

[Anjeyelf (anjeyelf)]

(In reply to BOB from comment #10)
> I don't know about the other steps #2-#4 so I am not trying them.

THUNDERBIRD - In Preferences > General
Files & Attachments
What have you got set for Content Type: HTML documents ?
Usually it is a browser of choice.

There is definity a bug of some sort causing the problem. Perhaps some Firefox code which has got used in Thunderbird.
Some people get pdf's opening in a browser as if a html document - I had this and noticed my Firefox browser had pdf's opening in Firefox. Others get a message saying a preference is not set, so I'm wondering if those people do not use Firefox.
Knowing if this is the case would be useful.

So what have you get set up in Thunderbird to open HTML documents?

[Infobob (infobob)]

Microsoft Edge HTML Document Always ask

[Infobob (infobob)]

Seems to be working now. I changed Portable Document Format (PDF) back to use Adobe Acrobat (DC) Default
and now it prompts first and then will open the pdf file. Good enough.

Now all they have to fix is when TB is opened it actually goes out to check for incoming mail like it used to without me having to click on Get Messages or press F5 to refresh. Thank you.

[Anjeyelf (anjeyelf)]

Reports occuring in Support Forum.
https://support.mozilla.org/en-US/questions/1359046

Either pdf is auto opening in firefox
OR getting error message "Attachment could not be opened, because the associated helper application does not exist. "

Due to pdf's being seen as HTML documents.

Some workarounds exist:
see comment #8 and comment #9

If getting the error message set up the 'HTML' document to 'Always ask' or choose the actual pdf program.

Hopefully the developers are working on discovering why the pdfs are seen as HTML and why it is neccessary to alter the Content Type: HTML document to use Adobe or Ask.

[Fsteiner-board (fsteiner-board)]

The workarounds are not helpful if you a) want to view pdfs in an external viewer like acroread *and* b) want to view html attachments in Firefox. That would only work if FF itself opens pdfs in the external viewer (but means the pdf is saved twice). Better workaround would be a little shell script as helper for html attachments in TB which will determine the filetype and send it to either FF or e.g. acroread. One-liner in Linux, sth. like `/usr/bin/file "$@" |/usr/bin/grep -q -i pdf && /usr/bin/okular "$@" || /usr/bin/firefox "$@"`

Unfortunately, it seems that devs are ignoring this bug so far as it has not been assigned to anyone.

[Mkmelin+mozilla (mkmelin+mozilla)]

*** Bug 1749905 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

*** Bug 1751502 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

*** Bug 1745232 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

*** Bug 1743585 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

*** Bug 1743801 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

Created attachment 9260253
Screenshot 1: Double-click on PDF attachment from composition suggests opening with browser

Depending on their settings, users will face different challenges with this bug.
The screenshot shows one likely variant.
Not sure why it's claiming that Edge is the default browser, because I have Firefox set for that.

[Bugzilla2007 (bugzilla2007)]

I might have duped to here a bit too generously.
Is the problem that a number of using are failing to open their PDF files from composition entirely (e.g. with an error message that helper application could not be found) related to this bug?

Overall, it does look as if we have UX problems around here which should be fixed asap.

[Bugzilla2007 (bugzilla2007)]

Excellent analysis by Henry as usual, can we find someone to pick up from here?
Too many duplicates here even if we subtract some which may not be directly related.
In terms of UX, this can cause considerable annoyances / inefficiencies for daily routines depending on users overall setup/preferences (between TB, browser, external apps).

(In reply to Henry Wilkes [:henry] from comment #0)
> Also get the printed error message
>
> ```
> JavaScript error: resource://pdf.js/PdfStreamConverter.jsm, line 140: TypeError: can't access property "getInterface", requestor is null
> ```

Error still seen in 98.0a1 (2022-01-21) (64-bit), Win10:
```
TypeError: can't access property "getInterface", requestor is null PdfStreamConverter.jsm:140:13
    getDOMWindow resource://pdf.js/PdfStreamConverter.jsm:140
    onStopRequest resource://pdf.js/PdfStreamConverter.jsm:1281
```

[Mkmelin+mozilla (mkmelin+mozilla)]

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?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(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 handli...

[Mkmelin+mozilla (mkmelin+mozilla)]

Thanks! That suggestion works well for me.

[Mkmelin+mozilla (mkmelin+mozilla)]

Created attachment 9260399
Bug 1698140 - don't do pdf.js stream conversion when there is no DOM. r=Gijs

This was at least a problem in Thunderbird, if people were set to use default system PDF viewer and clicked open pdf attachment for the message they were writing.

[Bugzilla2007 (bugzilla2007)]

*** Bug 1751502 has been marked as a duplicate of this bug. ***

[Bugzilla2007 (bugzilla2007)]

Thanks Magnus for tackling this UX problem! Seems like patch is almost there. Any chance to finish this off, with or without a test?

[Mkmelin+mozilla (mkmelin+mozilla)]

It's in my queue. I'll have to debug a bit more to understand what's going on.

[Xavier Guillot (valeryan-24)]

Error message when launching a pdf from attached files in Compose window, on a computer where Firefox is removed (replaced by Librewolf as default browser), instead of opening it with Evince.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Do you use the deb or the snap for thunderbird and evince?

[Xavier Guillot (valeryan-24)]

Hi, both deb versions - no snap

[Mkmelin+mozilla (mkmelin+mozilla)]

*** Bug 1775496 has been marked as a duplicate of this bug. ***

[Olivier Tilloy (osomon)]

This sounds very much like bug #1945741, which was an upstream bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1734428), but was marked as fixed 9 months ago. So it's probably a slightly different variation of that bug. Would you mind filing a new bug report at https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird, mentioning that other upstream bug, and sharing the link to it here?

[Xavier Guillot (valeryan-24)]

Hi, thanks for the answer.

Upstream report done :
https://bugzilla.mozilla.org/show_bug.cgi?id=1783679

[Bugzilla2007 (bugzilla2007)]

*** Bug 1783679 has been marked as a duplicate of this bug. ***

[Xavier Guillot (valeryan-24)]

Duplicate of upstream bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1698140

[tim (tc68)]

I came to report this bug but found it is already here.

I am on linux (Pop!_OS 22.04 LTS) and am using Thunderbird 102.2.2, although this was also present in version 91 (I only upgraded recently).

I have Thunderbird set to use the system PDF application (in this case Evince) for reading PDF files, which works perfectly for reading messages sent to me.

However, when I attach a PDF document to an email and try to open it to check something, it only gives me the option for Firefox. Fortunately, Firefox can display PDF files but it is not the behaviour I expected.Thanks for digging into it.

[Jeff Bloomfield (jeffb+lmi+net)]

It's been 6 months since this bug was assigned. Perhaps it could be reassigned to someone who has the time to look at the bug and fix it?
Much appreciated. (This was not a problem until T-bird > 63, I believe).