User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050104 Red Hat/1.4.3-3.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050104 Red Hat/1.4.3-3.0.7 Unable to open Visio (vsd) attachments from Thunderbird 1.0 on a WinXP SP2 client (also reported in BUG 24878). Will only allow me to save the attachment, and then I can open it by clicking on the file with Visio. This is a repeatable issue. Please reference the attached screen capture for visual details of the dialog box. I also, tried sacing the file with a different name and sending it to myself, which produces the same inability to open result. Reproducible: Always Steps to Reproduce: 1.open message from TB 1.0 2.Click on vsd attachment 3 [review].Pops up dialg box Actual Results: Please read details and view screen capture document. Expected Results: I should be able to either open or save the Visio attached document.

The attachment come with what for an mime-type and which client is used to send the message ? (see the message source)

Here is the message MIME type of the email message with the Visio Magnex.vsd attachment (Also, I used for this test the same system WinXP SP2 - TB 1.0 client): Message-ID: <42014905.6080302@varianinc.com> Date: Wed, 02 Feb 2005 13:41:25 -0800 From: Bill Quon <bill.quon@varianinc.com> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Quon <bill.quon@varianinc.com> Subject: Visio Content-Type: multipart/mixed; boundary="------------080108020900000307050600" This is a multi-part message in MIME format. --------------080108020900000307050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit

It's because .vsd is considered a potentially dangerous (executable) file type like .exe or .pif. Mozilla uses the same list as Microsoft does for IE. So the result you are seeing is intentional I'm afraid.

(In reply to comment #5) > It's because .vsd is considered a potentially dangerous (executable) file > type like .exe or .pif. Mozilla uses the same list as Microsoft does for IE. > So the result you are seeing is intentional I'm afraid. Do you have a source for that assertion, or are you speculating? .DOC files are *also* potentially executable, but it's no problem to configure TB to open a . DOC attachment in Word.

(In reply to comment #6) > (In reply to comment #5) > > It's because .vsd is considered a potentially dangerous (executable) file > > type like .exe or .pif. Mozilla uses the same list as Microsoft does for IE. > > So the result you are seeing is intentional I'm afraid. > > Do you have a source for that assertion, or are you speculating? .DOC files are > *also* potentially executable, but it's no problem to configure TB to open a . > DOC attachment in Word. No speculating, see http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#1931. The change was made by Bug 239160. From the Office formats some like DOC/XL?/PP? were intentionally left out (because to often used, but MD? and VSD not, see bug 239160 comment 21 et seq.). HTH

Guys, you really don't leave me much hope on trying to further the adoption of TB 1.0 as a viable email client. Currently, Varian is an Eudora shop and has taken the sendmail/POP3 client approach to offering a corporate email solution. After reading the last entry on this bug entry, I decided to dig a bit deeper. It appears MS has posted a solution for their Outlook client, which is referenced here: Cannot open attachments in Microsoft Outlook http://support.microsoft.com/default.aspx?scid=kb;en-us;829982 Since, I do not use this client, I did not try this, but is there a way to take this approach with TB 1.0? Please advise. Thanks, Bill

I suggest you reread the page you linked to. Thunderbird forces you to save the file and manually open it. Outlook does the same until you install Office 2003 SP1, where it stops you from accessing the file *altogether*. No open. No save. Nada. Since your complaint is not having easy access to the file, I don't think you want the MS approach... As an aside - if Microsoft deem their own file format dangerous enough to block *completely*, what aren't they telling us? Reresolving INVALID

Here is an excerpt form the MS link in comment #8; I provide this as a thought provoking message of a way that MS is allowing there customers to open documents, and honestly thought that it might also be possible to achieve with TB 1.0. However at this juncture, I am concluding that TB 1.0 is more rigid than other prodcuts. 1. Quit Outlook if it is running. 2. Click Start, and then click Run. 3. In the Open box, type regedit, and then click OK. 4. Verify that the following registry key for your version of Outlook exists. If it does, go to step 5. Microsoft Outlook 2000: HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Outlook\Security Microsoft Outlook 2002: HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Security Microsoft Office Outlook 2003: HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security If the registry key does not exist, create it. To create the registry key, locate and then click the following registry key: HKEY_CURRENT_USER\Software\Microsoft a. Click the Edit menu, click New, and then click Key. b. Type Office, and then press ENTER. c. Click the Edit menu, click New, and then click Key. d. Type 11.0, and then press ENTER. Note This is the correct name if you are using Outlook 2003. If you are using Outlook 2000 or Outlook 2002, you will have to type "9.0" or "10.0", respectively. e. Click the Edit menu, click New, and then click Key. f. Type Outlook, and then press ENTER. g. Click the Edit menu, click New, and then click Key. h. Type Security, and then press ENTER. 5. Click the Edit menu, click New, and then click String Value. 6. Type the following name for the new value: Level1Remove 7. Press ENTER. 8. Right-click the new string value name, and then click Modify. 9. Type the file name extension of the file type that you want to open in Outlook. For example: .exe To specify multiple file types, use the following format: .exe;.com 10. Click OK. 11. Quit Registry Editor. 12. Restart your computer. When you start Outlook, you can open the file types that you specified in the registry. Note We recommend that you enable only the file types that you require. If you rarely receive a particular file type, we recommend that you give Outlook temporary access to the file type that is in question and then reconfigure Outlook to block the file type by undoing the changes to registry.

Reporter, I would suggest you transform this bug to an RFE/enhancement which says "Provide an option (hidden pref) to open files which are supposed to be potentially dangerous (like .exe, .scr) directly like normal formats" or something similiar. M$ provides also only a "hidden pref" (manual edit of the registry).

FYI - the outlook registry key modification transforms the previously mentioned complete blocking behaviour (*no access* to the attachment *at all*) into what Thunderbird gives you *NOW*.

The situation w.r.t. this bug has changed a bit in the latest builds. The new Preferences dialog includes a somewhat different Change Action dialog for setting the preference on the files. With a .VSD file, the "default action" is selectable, but -- depending on how odd your mimeTypes.rdf file has gotten by manual tweaking -- it may show a blank entry for the "default action". However, the "open with" action now behaves as expected! If you select Visio as the custom program, then close the dialog, then select Change Action again: TB doesn't immediately reopen the Select File dialog to pick the preferred application again; instead, the program name is maintained, and the radio button is still selected. More importantly: it is used -- double-clicking a VSD attachment opens it up. Even better: you don't necessarily need to run a new build -- the problem appears to be with how the .RDF file was stored. If I run TB 1.0 after making the changes with the trunk build, *it too* can open .VSD files. The critical data seems to be this entry in mimeTypes.rdf: <RDF:Description RDF:about="urn:mimetype:handler:application/vnd.visio" NC:alwaysAsk="false" <!-- THIS --> NC:useSystemDefault="true" <!-- AND THIS --> NC:saveToDisk="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vnd.visio"/> </RDF:Description> I'll put more detail at bug 261766. Bill Quon, if this development suits you, please mark this bug Resolved | WorksForMe or else say what else you need.

Urg. See bug 261766 comment 27. Having had to re-evaluate this mess, I now see that unless you're willing to hack around in mimeTypes.rdf, current builds *still* do not let you specify a default action. Something *has* changed, which allowed my hacked-up mimeTypes.rdf to suddenly get handled reasonably and then written out in a form that works for both 1.0 and trunk builds, but it's definitely still a hack to workaround the blacklisting of VSD's. Attachment 177235 [details] from that bug has the working mimeTypes.rdf information.

I made the changes to my mimeTypes.rdf file as suggested and was able to open a Visio file attachment after double clicking on it. The changes do not present the dialog box as before, but only flashes it and then immediately opens the vsd file. However, if I right click the attachment, I am presented with a small dialog box with an Open, Save As, and Save All options list. This is an improvement, but not quite right yet. I'll live with the modified mimeTypes.rdf suggestions, sinc it does provide me with a work around, but work still needs to be done to get it to behave similiarly with other file attachment types. Thanks!

(In reply to comment #15) > However, if I right click the attachment, I am presented > with a small dialog box with an Open, Save As, and Save All options list. You mean the context menu? What's the problem with that? That's how right- click *always* works on an attachment; and select Open from the menu works as expected for me. I have since noticed a problem where Visio docs only opening once; I'm not sure what's causing this, but subsequent attempts to open result in a File Not Found error. I could duplicate this with another attachment type.

Please the file "TB 1.0 - After mimeType Changes" for screen captures of the dialog boxes depicting the behavior of TB while manipulating an attached Visio "vsd" file. I hope this helps to explain my current situation. Please note, that if it where a different type of file attached (pdf, doc. xls), a dialog box would have appeared when the file was double clicked, providing the followin options: Open with, Save to Disk, (check box) Do this automatically for files like this from now on. I am wondering, if this last option is being implied somehow.

Do you think you could possibly learn how to post the image directly, instead of subjecting us to these damned Word documents? Use a nice compact format, like PNG or JPG or GIF. (Visio can handle all of those.) Even better to provide an image of only the relevant window instead of the entire screen (Alt-PrtScrn instead of Shift-PrtScrn). But right now, I don't need any more screenshots at all; I just want an answer to one question, at the end of this comment. (In reply to comment #17) > if it where a different type of file attached (pdf, doc. xls), a dialog > box would have appeared when the file was double clicked, providing the > followin options: Open with, Save to Disk, (check box) Do this automatically > for files like this from now on. > > I am wondering, if this last option is being implied somehow. I assume this is related to the first screenshot in that file. Yes, the "do this automatically" option *is* being implied; an entry in the mimeTypes.rdf file *implies* that TB will handle the attachment type automatically when directed to "Open" the attachment. In fact, that's what I thought you wanted. If you want double-click (which is the same as "Open" from the context menu) to present that dialog with Open and Save options for Visio files, that's not currently possible, and won't be until such point as .VSD is removed from the "dangerous file extensions" list. Regarding the second screenshot: Is there, or is there not, some problem with the right-click action, which is what I asked about in comment 16? The screenshot shows the expected action for that case, and would be the same for a right-click on *any* type of extension.

There are no further issues, the right click function is working fine, so my case is closed.

-> wfm (per comment #19)