Closed Bug 274508 Opened 20 years ago Closed 16 years ago

Setting Default application (e.g. for PDF) disallowed due to disabled checkbox

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: colleen.beamer, Unassigned)

Details

I'm running Thunderbird in Fedora Core 2.  This is the situation in my environment:

When I receive a pdf attachment in Thunderbird and double click to
open it, I get a window that asks what Thunderbird should do with the
file.  The choices are "Open with" and this defaults to gpdf,  but
"Other ..." can be selected from a drop down menu,  and "Save to Disk".

If I select to "Open with" and "Other..." and choose to open it with
acroread, this works.  However in the window, the last item is a tick
box which I should be able to select.  This box tells Thunderbird to
"Do this automatically for files like this from now on".  The problem
is that it is grayed out and I can't select it.  I have looked at a
number of configuration preference files and can't figure out where to
set this.  Besides, I would think that I should be able to do it from
within Thunderbird.
xref bug 261766 comment 13 et seq -- altho the specific problem I was having 
with Visio files turns out to hinge on the fact that .VSD files are always not 
openable (due to alleged virus-carrying capabilities), the description of how to 
edit the mimeTypes.rdf file may be helpful.
Colleen Beamer, please see bug 261766 comment 26 -- please report whether a 
current trunk build also addresses your problem.
(In reply to comment #2)
> Colleen Beamer, please see bug 261766 comment 26 -- please report whether a 
> current trunk build also addresses your problem.

No, a current trunk build didn't fix the problem.  I installed a trunk build
dated March 12 and the problem wasn't resolved.  My problem exists on a Linux
system, not Windows, so I'm not sure of the relevance of referring me to a bug
related to Visio.  Regardless, the problem wasn't resolved.  It is not a
critical issue, just something I would like to be able to do.  Thanks.  :-)


The relevance is whether or not you can specify a non-default application to 
handle attachments.  That was (part of) the problem getting Visio to open.

I'm not sure if when you tested you simply tried to open the PDF attachment, or 
if you actually went into   Tools | Options | Attachments   and tried to re-
specify the application -- the latter is what I intended for you to try.
In the Thunderbird trunk build that I used (Mar. 12th), I didn't have
"Tools-Options-Attachments".  In my environment, it was
"Edit-Preferences-Attachmments".  On that screen, there was a button to "View
and Edit Actions".  When this button was pressed, there were no actions listed
and the "Remove Action" "Change Action" buttons were grayed out.

Hope this clarifies things.  I am reverting to the 1.0 build of Thunderbird
because I use Enigmail and the 0.90.2 version of Enigmail does not seem to work
with the Thunderbird trunk build of March 12th.  I know this is not relevant to
this bug, but I wanted to let you know.

Thanks:-)
> "Edit-Preferences-Attachmments".  On that screen, there was a button to "View
> and Edit Actions".  When this button was pressed, there were no actions listed
> and the "Remove Action" "Change Action" buttons were grayed out.

"No actions listed" meaning no entries at all, I take it: that table has entries 
listed by file extension, so there could be a PDF, a DOC, a ZIP, etc.  Does the 
analogous screen also show no entries at all when viewed in 1.0?

Part of the symptom of the bug that was fixed is, when the config data in 
mimeTypes.rdf is actually *correct* for specifying that an attachment type 
should be opened by a non-default app, the entry doesn't appear in that table in 
the Prefs dialog (in 1.0).  Perhaps you're seeing a similar situation with a 
possibly bogus mimeTypes.rdf file being misdisplayed in the trunk version.

You can look at mimeTypes.rdf (in your profile directory) if you're so inclined.
You might also try: create a new profile (using the trunk version); compose a 
message with a .pdf attachment; save it as a draft (or Send Later, or send it to 
yourself); view the copy of the message in your Draft/Unsent/Sent folder, and 
double-click the attachment; proceed as normal to select the app and check "Do 
this automatically".  Verify this is working by double-clicking the attachment 
again.  If it works, copy the mimeTypes.rdf file from the new profile to the old 
profile.


> I am reverting to the 1.0 build of Thunderbird

You should be able to run the two versions in parallel, from separate install 
directories; whichever one is running will find the profiles.  Just run the 
trunk version in SafeMode for testing, to avoid conflicts with Enigmail.
(In reply to comment #6)
> > "Edit-Preferences-Attachmments".  On that screen, there was a button to "View
> > and Edit Actions".  When this button was pressed, there were no actions listed
> > and the "Remove Action" "Change Action" buttons were grayed out.
> 
> "No actions listed" meaning no entries at all, I take it:

That was true with the trunk build dated March 12th, that I used.  After I sent
this message, I tried a build dated March 13th and now, I have an entry that
specifies to open .doc files with AbiWord and the "Remove Action" and "Change
Action" buttons now work.  (Also, irrelevant to this bug, I now have my Enigmail
working with the build dated March 13th.) 
 
that table has entries 
> listed by file extension, so there could be a PDF, a DOC, a ZIP, etc.  Does the 
> analogous screen also show no entries at all when viewed in 1.0?
> 
> Part of the symptom of the bug that was fixed is, when the config data in 
> mimeTypes.rdf is actually *correct* for specifying that an attachment type 
> should be opened by a non-default app, the entry doesn't appear in that table in 
> the Prefs dialog (in 1.0).  Perhaps you're seeing a similar situation with a 
> possibly bogus mimeTypes.rdf file being misdisplayed in the trunk version.
> 
> You can look at mimeTypes.rdf (in your profile directory) if you're so inclined.
> You might also try: create a new profile (using the trunk version); compose a 
> message with a .pdf attachment; save it as a draft (or Send Later, or send it to 
> yourself); view the copy of the message in your Draft/Unsent/Sent folder, and 
> double-click the attachment; proceed as normal to select the app and check "Do 
> this automatically".  Verify this is working by double-clicking the attachment 
> again.  If it works, copy the mimeTypes.rdf file from the new profile to the old 
> profile.

This is what I was trying to specify in the bug report that I filed.  If I
double click on the .pdf file, a screen appears with the prompt:  Open with:
which defaults to ggv, but there is a drop down menu from which I can select
"Other".  There is a selection for "Save to disk" and the final tick box on the
screen has the text "Do this automatically for files like this from now on", but
even if I select "Other" and navigate to the location of the executable acroread
so that this appears in the text box for the drop-down menu, the "Do this
automatically ..." text is grayed out I can't select the tickbox, which is what
I want to do.

I DID look at my mimeTypes.rdf file, but it makes no mention of .pdf files, only
MS Word which is to be opened with AbiWord.
OK.  I've gone back and carefully reread that bug, and I now see I've quite led 
that bug astray; see bug 261766 comment 27.

That bug's reporter has posted screenshots showing the "What should Thunderbird 
do with this file?" dialog with the OK button disabled, and also with the "Do 
this automatically..." checkbox disabled.  The latter symptom is, of course, 
what you are reporting.  That bug was *also* reported originally under Linux.

I'm confirming based on the duplicate symptom reported there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Setting Default pdf application → Setting Default application (e.g. for PDF) disallowed due to disabled checkbox
I think I've found (one anyway) reason for the inability to change the
application that deals with a particular mime type (at least on Linux - I'm
using Fedora Core 3).  I discovered that there are three entries in my
/etc/mailcap file that appear to determine how Thunderbird will react to msword,
pdf, and postacript documents.  For the pdf documents there's an entry

application/pdf; ggv %s

I changed ggv to /usr/local/Acrobat5/bin/acroread and Thunderbird now suggests
acroread as the default application for pdf files.

Roy
(In reply to comment #9)
> I think I've found (one anyway) reason for the inability to change the
> application that deals with a particular mime type (at least on Linux - I'm
> using Fedora Core 3).  I discovered that there are three entries in my
> /etc/mailcap file that appear to determine how Thunderbird will react to msword,
> pdf, and postacript documents.  For the pdf documents there's an entry
> 
> application/pdf; ggv %s
> 
> I changed ggv to /usr/local/Acrobat5/bin/acroread and Thunderbird now suggests
> acroread as the default application for pdf files.
> 
> Roy


Well, this fixes the problem if you permanently want to change the pdf viewer
to, say acrobat reader.  However, if you later permanently want to change it to
another pdf view, the only way to do this is by editing the mailcap file.

This is a good interim solution and sort of stops my personal gripe since now,
when I view pdf files, acrobat will be used.  However the Thunderbird should
work properly in that you should be able to select the application that you want
to use and use the provided tick box to tell Thunderbird to "Do this
automatically for files like this from now on".
I've encountered this bug on RedHat FC3, and Suse 9 and 10.
Changing /etc/mailcap does not change Thunderbird's suggested actions,
nor are they changeable.  Nor can you add an action via the preferences->attachments->Download Action, View/Edit actions dialog box.

I'm testing "straight" TB 1.5.
I can confirm this on 1.5.0.2 on Linux FC.  

Sure, it asks you for "what action do you want to take?" 

And lets you choose acroread (for a pdf, as an example)

And does NOT let you check the "do this always" button.

So next time you have to go through it all over again.

Can we get the priority escalated for a fix?  I actually use TB to read mail - (There are days I think everyone else just tries it out for novelty's sake)

most likely, the sending program is not setting the content type to application/pdf, but rather, application/octet-stream. We only remember decisions based on content type, not file extension.
I've just tested this and Thunderbird is broken even if the content type is set to application/pdf.


(In reply to comment #13)
> most likely, the sending program is not setting the content type to
> application/pdf, but rather, application/octet-stream. We only remember
> decisions based on content type, not file extension.
> 

Here's the header:

----------------------
Content-Type: application/pdf;
 name="file06.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="file06.pdf"


Additionally, Thunderbird figures out that an extension of .pdf
means to use gpdf, even if the content type is application/octet-stream.
It's just that this behavior can not be changed.


(In reply to comment #13)
> most likely, the sending program is not setting the content type to
> application/pdf, but rather, application/octet-stream. We only remember
> decisions based on content type, not file extension.
> 


Well, I've read through this bug, and number of bugs attached to it, and I'm now hopelessly confused about what is considered a separate bug, what can be worked around how, and generally whether there's any plans to fix the problem.

If somebody could clarify the situation, I'd love it.

I'm trying to open a CSV file, attached to a message with a content-type of "application/octet-stream" (wrong, I know, but it happens a lot and Thunderbird ought to be able to figure out the content from the extension), using Thunderbird 1.5.0.7, under Linux.

When I double-click the attachment to open it, the "opening" dialog has a very limited choice of "Open with" applications, and the "Do this automatically" box is greyed out. The "Open with ... Other" option does work - but obviously I have to go and find oocalc every time I want to open such a file.

I think comment 13 confirms what I'm saying - but unfortunately doesn't give any idea of why this has to be so.
(In reply to comment #16)
> I think comment 13 confirms what I'm saying - but unfortunately doesn't give
> any idea of why this has to be so.

Because application/octet-stream is used for all sorts of files; if you set the default for your spreadsheet and then get a JPEG with that type, that image would be passed to the spreadsheet program.
(In reply to comment #17)
> (In reply to comment #16)
> > I think comment 13 confirms what I'm saying - but unfortunately doesn't give
> > any idea of why this has to be so.
> 
> Because application/octet-stream is used for all sorts of files; if you set the
> default for your spreadsheet and then get a JPEG with that type, that image
> would be passed to the spreadsheet program.

Yes - but that doesn't explain why Thunderbird can't make associations by filename whne the mime-type is application/octet-stream.
QA Contact: preferences
Assignee: mscott → nobody
>Yes - but that doesn't explain why Thunderbird can't make associations by
>filename whne the mime-type is application/octet-stream.

It could do that but it should not, that's by design for security reasons.

According to RFC 2046 (addressing security
issues in MIME types), under section 4.5.1 for application/octet-stream
entities:

   "The recommended action for an implementation that receives an
   'application/octet-stream' entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

   To reduce the danger of transmitting rogue programs, it is strongly
   recommended that implementations NOT implement a path-search
   mechanism whereby an arbitrary program named in the Content-Type
   parameter (e.g., an 'interpreter=' parameter) is found and executed
   using the message body as input."
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.