Thunderbird refuses to open master pdf editor in write window
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: ToddAndMargo, Unassigned)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
Fedora 35, x64
thunderbird-91.4.0-1.fc35.x86_64
When I attach a PDF in my write window, it is ABSOLUTELY IMPERATIVE that I be able to review the thing befoe sending it to a customer.
Problem: Thunderbird refuses to open Master PDF Editor.
Actual results:
Idiot error message. See attachments
Expected results:
Open Master PDF Editor
Comment 3•4 years ago
|
||
Thank you Todd, and sorry for the inconvenience. Agreed that previewing PDFs before sending them out is absolutely imperative. We must fix this.
In the meantime, you could try the workaround along bug 1698140 comment 8.
Comment 4•4 years ago
|
||
Or maybe I spoke too fast, and this is another problem...
(In reply to Thomas D. (:thomas8) from comment #4)
Or maybe I spoke too fast, and this is another problem...
This issue is not being able to find the application that the PDF is associated with, not rendering incorrectly.
Would you remove the duplication?
Comment 6•4 years ago
|
||
Hi Todd, thanks for your feedback!
(In reply to Todd from comment #5)
This issue is not being able to find the application that the PDF is associated with, not rendering incorrectly.
Bug 1698140 isn't about incorrect rendering, it's exactly about similar problems as yours, and I'm still suspecting it is actually your problem. We can reopen until we have positive affirmation for that.
Have you actually tried (or at least read and understood) the proposed workaround in bug 1698140 comment 8?
That bug effects the following:
- You're trying to open a TB attachment from composition.
- TB sees/treats that as an HTML file, not a PDF file
- Your TB PDF handling options are bypassed (so it won't matter if they all look good)
- Your Firefox PDF handling options will handle the file you opened from TB (iiuc). Got it?
So we need a lot more detail from you to understand what you're doing, and what your settings are.
- Please provide full steps to reproduce (a numbered list of actions to perform to get into your scenario).
- Please provide full details of your TB and Firefox settings for handling PDF and HTML files.
- Please avoid disrespectful words like 'Idiot error message'. Whilst we understand the frustration, venting won't solve the problem, on the contrary.
Comment 7•4 years ago
|
||
Comment on attachment 9260224 [details]
PDF association
- Are these your PDF settings for TB or FF? (see comment 6)
- Have you tried to remove the action, close TB, and reset the action (maybe stale path, unfortunately I don't know how to check the actual path)?
Comment 8•4 years ago
|
||
Comment on attachment 9260225 [details]
Application Details
- Where does this screenshot come from? Is it part of Thunderbird UI?
Disclaimer: I'm not using Linux.
Comment 9•4 years ago
|
||
Comment on attachment 9260223 [details]
Incorrect error message when trying to view an attached PDF
.
| Reporter | ||
Comment 10•4 years ago
|
||
| Reporter | ||
Comment 11•4 years ago
|
||
A) set Master PDF Editor as you default PDF viewer
→ Edit → Preferences → General → Files & attachments
B) verify that from your inbox that you can read a PDF attachment with Master PDF Editor. This verifies that the association’s path is correct
C) open a compose window, plain text or HTML, does not matter
D) attach a PDF
E) attempt to view a PDF with Master PDF Editor from the compose window.
Now as a test, I set HTML's association in Files & Attachments to Brave Browser. When I go to view a PDF in a compose window, it opens Brave Browser, NOT WHAT I STATED A PDF SHOULD OPEN WITH. Setting HTML back to Firefox opens the PDF in FIREFOX, now without the path error message.
So, what to fix is ONLY OPEN WHAT IS STATED IN Files & Attachments. NO OVERRIDING THE USER'S PREFERENCES. A PDF file is not an HTML file. The PDF rendering engines in Firefox, Brave, etc. ARE REDUCED FUNCTION rendering engines and make tons very FRUSTRATING errors. If I state I want Acme PDf Editor to open a PDF, THAT IS WHAT I EXPECT. NO GOING OFF ON TANGENTS.
Comment 12•4 years ago
•
|
||
(In reply to Todd from comment #11)
Thanks Todd for fast reply!
Wrt comment 10, Application Details dialog - you've just taught me a new trick! First time to see this. Only present after custom apps have been chosen, then shows them all, will not preselect the currently chosen one, and selection in that dialog won't affect the chosen default action app (so the dialog is really just for manually viewing the details of each possible previous app, except the OS default app, which isn't listed).
A) set Master PDF Editor as you default PDF viewer
→ Edit → Preferences → General → Files & attachments
Thanks for steps and testing! Helpful.
Now as a test, I set HTML's association in Files & Attachments to Brave Browser. When I go to view a PDF in a compose window, it opens Brave Browser, NOT WHAT I STATED A PDF SHOULD OPEN WITH. Setting HTML back to Firefox opens the PDF in FIREFOX, now without the path error message.
Right. So you're saying that TB takes PDFs as HTML files, which is where things get confusing and wrong. Correct.
So how is this different from Bug 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?
Seems to me your tests have verified my original understanding that this is a duplicate of bug 1698140...
So, what to fix is ONLY OPEN WHAT IS STATED IN Files & Attachments. NO OVERRIDING THE USER'S PREFERENCES. A PDF file is not an HTML file. The PDF rendering engines in Firefox, Brave, etc. ARE REDUCED FUNCTION rendering engines and make tons very FRUSTRATING errors. If I state I want Acme PDf Editor to open a PDF, THAT IS WHAT I EXPECT. NO GOING OFF ON TANGENTS.
Absolutely! It's annoying! I hear you, even without all the UPPERCASE (which may be read as shouting). Italics and Bold will do ;-)
| Reporter | ||
Comment 13•4 years ago
|
||
I am not exactly sure what the information request is.
As far as the similarity for bug 1698140, I can not say without seeing the source code and why the code thinks PDF is HTML in the compose window. And at the moment, I can only remember Perl 5 and 6 code. I would be doing a lot of guessing at C or Java.
And change you could post the section that interprets PDF and HTML?
I was not meaning shouting. I was meaning emphasis.
Comment 14•4 years ago
•
|
||
(In reply to Todd from comment #13)
I am not exactly sure what the information request is.
My question was: how is this different from Bug 1698140?
I can't see a difference. Your problem is caused by the mixup between PDF and HTML, and that's exactly Bug 1698140 afasics.
So let's duplicate again and wait for the outcome of that bug.
As far as the similarity for bug 1698140, I can not say without seeing the source code and why the code thinks PDF is HTML in the compose window. And at the moment, I can only remember Perl 5 and 6 code. I would be doing a lot of guessing at C or Java.
And change you could post the section that interprets PDF and HTML?
You can follow Bug 1698140 if interested, the person assigned there will find the code. It's JavaScript btw...
I was not meaning shouting. I was meaning emphasis.
Understood. It's all good. I wasn't sure either way (but I didn't feel shouted at), but in general, uppercase emphasis may easily be misread as emotional, and it's a bit bulky to read ;-)
Description
•