221451 - Open With radio button frequently disabled when opening an attachment

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Scott MacGregor]

With the new helper app dialog, thunderbird frequently gets in a state where the
"Open With" radio button is both disabled and fails to show the appropriate
application properly.

I see this after installing OpenOffice on a machine that has never had MSWord on
it. I then open a word document and I get this problem.

BMS is also reporting this issue with PDF attachments.

Comment 1

[Scott MacGregor]

We detect that the attachment is of type octet/stream so we disable the open
radio button and only enable the save button. In the octet/stream case we really
need to look at the file extension. This is what we used to do with the old
helper app dialog.

Comment 2

[Scott MacGregor]

I've made this marginally better in 0.3 and in the trunk by taking the following
fixes:

Bug #143570 --> Allow assigning helper apps to mailnews attachments by extension

and

Bug #65827 --> File extension (.php) determined from Content-Type header (or url
extension) overrides filename in Content-Disposition header.

Now instead of showing application/octet in the helper app dialog when opening
mail attachments, we show the correct mime type in the dialog (i.e. Microsoft
Word Document). 

However the helper app dialog still uses an application/octet-stream mime info
object and the security code in the dialog then disables the open radio button
even though we have a valid helper app for the real mime type. 

Comment 3

[Scott MacGregor]

Ok, I think I found the problem. It's with the new helper app dialog the birds use. 

initAppAndSaveToDiskValues does the following:

      // We don't let users open .exe files or random binary data directly 
      // from the browser at the moment because of security concerns. 
      var mimeType = this.mLauncher.MIMEInfo.MIMEType;
      if (mimeType == "application/octet-stream" ||
          mimeType == "application/x-msdownload") {
        this.dialogElement("open").disabled = true;
        var openHandler = this.dialogElement("openHandler");
        openHandler.disabled = true;
        openHandler.label = "";
        modeGroup.selectedItem = this.dialogElement("save");
        return;
      }

We should never look directly at the content type when determining if we are
going to block the open. We always need to look at the extension. This is how
the old helper app dialog works. In fact the same code for disabling the open
button is present in the new dialog too, it just has this extra blurb as well.

I think the fix is to just remove these lines.

We are already disabling the open with radio button in openWithDefaultOK which
properly tests to see if the file is an executable.

Comment 4

[Scott MacGregor]

Attachment: the fix

Comment 5

[Scott MacGregor]

Ben and I fixed the problem:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsHelperAppDlg.js&branch=&root=/cvsroot&subdir=mozilla/toolkit/mozapps/downloads/content&command=DIFF_FRAMESET&rev1=1.4&rev2=1.5

Putting this in 0.3 as well.