1698140 - PDF attachments treated as HTML when opened externally during composition (due to error in PdfStreamConverter.jsm), so users may face hurdles or fail to open the PDF depending on TB and browser settings

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect, P3)

Description

[Henry Wilkes (they/them) [:henry-x]]

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.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

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.

Comment 7

[Anje]

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.

Comment 8

[Anje]

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

Comment 9

[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!

Comment 10

[BOB]

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.

Comment 11

[WaltS48 [:walts48]]

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

Comment 12

[BOB]

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.

Comment 13

[Henry Wilkes (they/them) [:henry-x]]

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

Comment 14

[BOB]

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.

Comment 15

[Anje]

(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?

Comment 16

[BOB]

Microsoft Edge HTML Document Always ask

Comment 17

[BOB]

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.

Comment 18

[Anje]

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.

Comment 19

[Frank Steiner]

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.

Comment 25

[Thomas D. (:thomas8)]

Attachment: 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.

Comment 26

[Thomas D. (:thomas8)]

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.

Comment 27

[Thomas D. (:thomas8)]

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

Comment 28

[Magnus Melin [:mkmelin]]

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?

Comment 29

[:Gijs (he/him)]

(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?

Comment 30

[Magnus Melin [:mkmelin]]

Thanks! That suggestion works well for me.

Comment 31

[Magnus Melin [:mkmelin]]

Attachment: 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.

Comment 33

[Thomas D. (:thomas8)]

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

Comment 34

[Magnus Melin [:mkmelin]]

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

Comment 37

[Tim]

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.

Comment 38

[Jeff Bloomfield]

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).

Comment 39

[Diederik]

A workaround is to disable pdfjs in the config editor. Credit to scottishjon55 on reddit

See https://www.reddit.com/r/Thunderbird/comments/qrpmnb/cant_open_attachments_while_composing/

Comment 40

[quazgar]

Any news on this? There's a 3 years old patch which seems to need some caretaking?

Comment 41

[TB]

Thanks for getting back to this. At 140.5.0esr (64-bit) it is working (this way)

1. When composing a new message it opens PDF fine
2. When editing a message (as new) it opens PDFs with the name nsmail.pdf

I guess that is adequate. What do you think?

Comment 42

[TB]

And yes, in my case PDFs opened to FireFox. I did not test or try to use other PDF-viewers, if that has been a problem for some.

Comment 43

[TB]

And yes, in my case PDFs opened to FireFox. I did not test or try to use other PDF-viewers, if that has been a problem for some.

Comment 44

[Christian Großegger]

Attachment: Bug 1698140 - Don't claim PDF channels that have no browsing context in PdfStreamConverter. r=Gijs

When a consumer opens a PDF channel that is not a docshell/document load (e.g.
opening a PDF attachment from the Thunderbird compose window via nsIURILoader),
the channel has no targetBrowsingContext. getConvertedType currently still
rewrites the channel's type to text/html so PDF.js can take over - but PDF.js
cannot render without a DOM window, and the rewritten text/html type then breaks
the external-helper-app fallback. Bail out early so the load is handled normally
as application/pdf and routed to the user's PDF handler.

This implements the targetBrowsingContext check suggested in comment 29.

Comment 45

[Christian Großegger]

Post as a follow-up to the Phabricator revision (comment 44), which already
carries the full mechanism in its commit message. This comment only adds the
platform-divergence context + local verification (not duplicated by #44).
Keep the literal attachment 9260399 / comment 29 so Bugzilla auto-links.

---

The platform divergence behind the recent "works on Linux / on new messages"
reports (comment 41): it's one root cause — the text/html rewrite described in
the revision — with two symptoms. With no browsing context PDF.js can't render,
so the rewritten text/html type reaches the external helper app. On Windows
there is no usable text/html handler → NS_ERROR_FILE_NOT_FOUND ("… could not be
opened, because an unknown error occurred"). On Linux a text/html handler exists
→ it silently opens in the browser as nsmail.pdf, which is why it looks fixed
there. Same bug, just invisible on Linux.

Still reproduces on 140.10.2esr. I verified the patch locally (patched omni.ja):
the text/html rewrite disappears and the PDF opens in the configured external
application. The only gap versus the earlier approach (attachment 9260399 [details]) is
that the comment 29 targetBrowsingContext check was applied only to the
octet-stream path, not the main application/pdf path; the revision hoists it to
cover both.

Comment 48

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] (away until Aug 10) from comment #31)

Created attachment 9260399 [details]
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.

Comment 49

[Christian Großegger]

I'd like to take this, per Magnus' "Feel free to grab though" in D304451 - could someone
with editbugs reassign?

The fix there is essentially the one from D136749; what is new is the test. It opens the
PDF the way the compose window does - nsIURILoader, system principal, no
targetBrowsingContext - and asserts that the unknownContentType dialog appears instead of
PDF.js pulling the file into a tab. That answers "How does TB open the file, and can we not
reproduce that in a test?" from D136749, and it goes red without the guard.

Magnus, could you abandon D136749? Same fix, and its diff still targets the pre-ESM
PdfStreamConverter.jsm.

The Thunderbird-side test follows as a separate comm-central patch.

Comment 50

[Wayne Mery (:wsmwk)]

Christian, feel free to submit a new patch for review.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1f488676c110
https://hg.mozilla.org/integration/autoland/rev/310246c57ca8
Don't claim PDF channels that have no browsing context in PdfStreamConverter. r=Gijs,calixte

Comment 52

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/65e6250c7bfa
https://hg.mozilla.org/integration/autoland/rev/304ad2e0da16
Revert "Bug 1698140 - Don't claim PDF channels that have no browsing context in PdfStreamConverter. r=Gijs,calixte" for causing failures at browser_pdfjs_no_browsing_context.js. IGNORE BAD COMMIT MESSAGES

Comment 53

[Atila Butkovits]

Backed out for causing failures at browser_pdfjs_no_browsing_context.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/304ad2e0da16

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=310246c57ca832bf1831d116bb1d92973b4c56cb

Failure log: https://treeherder.mozilla.org/logviewer?job_id=585076314&repo=autoland&task=Osx6LRz_QX-YzldsWkLwnQ.0&lineNumber=72365

Comment 54

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9e8e6f61959b
https://hg.mozilla.org/integration/autoland/rev/bfb93fd71bb6
Don't claim PDF channels that have no browsing context in PdfStreamConverter. r=Gijs,calixte

Comment 55

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/bfb93fd71bb6

Comment 56

[Christian Großegger]

Attachment: Bug 1698140 - Test opening a PDF attachment from the compose window. r=mkmelin

Adds a browser-chrome test for the compose window's attachment-open path
(OpenSelectedAttachment in MsgComposeCommands.js). With PDF handling set to
"always ask" / external application, opening a PDF attachment must hand the file
to the external helper (the unknownContentType dialog) instead of being claimed
by PDF.js.

The attachment is loaded through nsIURILoader.openURI with a system principal and
no browsing context - the case the mozilla-central guard added for this bug
protects (D304451). This is the comm-central half, kept as a separate patch as
requested in review; it depends on that guard having landed.

Comment 57

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d003cb04a919
Test opening a PDF attachment from the compose window. r=mkmelin