+++ This bug was initially created as a clone of Bug #446291 +++ This is the Thunderbird counterpart to SeaMonkey bug 462629, since Thunderbird has now adopted the new attachments actions dialog initially introduced by Firefox. This dialog is insufficient for mail/news in the common case of wrong associations between file extensions and MIME types. Such issues cannot easily be detected and not be resolved within the current dialog. Specifically missing are: 1) display of associated file extensions; 2) removing a wrong entry (only the action can be removed); 3) adding an entry from scratch. Item #3 is specific to Thunderbird as (in contrast to SeaMonkey) it is not possible to define an association just by drag-and-drop of a file of that type into the browser window. Given the user confusion these issues are frequently causing, it would be beneficial to reintroduce these functions.

As can be seen, the image/gif MIME type has been associated with a PNG image based on a malformed attachment being previously opened. Even though the MIME types are shown, the only association with the ".png" file extension is given by the "PNG Image" description taken from the Windows File Type definitions. Outgoing e-mails may randomly send .png files as image/png or image/gif based on the conflicting entries. There is no "Remove" item in the drop-down list for that entry. A mimeTypes.rdf test file is provided in bug 462629 attachment 345836 [details].

I would also really like it to have an option to add/remove mimetypes. I have two "wrong" mimetypes in the attachment pane, but the only way to remove it, is to hack mimeTypes.rdf. This is not very user-friendly.

Firefox has an Application prefpane that might be of some interest. See https://bugzilla.mozilla.org/show_bug.cgi?id=414493#c4

Well, that's the pref pane which was just implemented by bug 446291 with its insufficiencies for verifying/configuring the file-type associations. Or are you referring to something else? You can edit the application and select "Always ask" to prompt for the dialog, thus bug 414493 should be WFM by now. The problem here is that you can neither edit the file-type association nor remove an entry if it seems to be wrong. Additionally, to create a new MIME entry, you basically have to send yourself a message with a respective attachment and open it, a rather odd procedure.

(In reply to comment #4) > Well, that's the pref pane which was just implemented by bug 446291 with its > insufficiencies for verifying/configuring the file-type associations. Or are > you referring to something else? No, I just didn't recognize it as the firefox prefpane, which I thought would be more suitable to mailnews prefs. > You can edit the application and select "Always ask" to prompt for the dialog, > thus bug 414493 should be WFM by now. The problem here is that you can neither > edit the file-type association nor remove an entry if it seems to be wrong. > Additionally, to create a new MIME entry, you basically have to send yourself a > message with a respective attachment and open it, a rather odd procedure. I agree that the user mimetypes.rdf should be fully editable. IE: add and edit existing associations. I think we need to expose windows file extensions also for clarity.

(In reply to comment #0) > This dialog is insufficient for mail/news in the common case of wrong > associations between file extensions and MIME types. Such issues cannot easily > be detected and not be resolved within the current dialog. I'm wondering if there another place we could fix this problem as well. I don't think I really understand what is happening and don't have a test mail to play with. But when wrong associations are made between file extensions and MIME types it seems like at association time (while viewing the attachment) could be a place where we could help more people fix this issue without going into the prefs. > Specifically missing are: > 1) display of associated file extensions; It is a rich list item so I think someone could attempt making this addition. > 2) removing a wrong entry (only the action can be removed); At minimum I think a context menu 'Remove' option could make sense. > 3) adding an entry from scratch. I think this has value but I would have to prioritize this below the other items related to fixing incorrect entries. Fixing the incorrect entries seems like the greater concern and this more of a feature (as I see it right now). Unless I'm misunderstanding this, lets spin this one piece off as a separate bug. > Item #3 is specific to Thunderbird as (in contrast to SeaMonkey) it is not > possible to define an association just by drag-and-drop of a file of that type > into the browser window. Is it possible or reasonable for Thunderbird to provide a "canned" set of common MIME types? I know that wouldn't solve this problem but it would alleviate some of this concern because we might already have some of the types you would want to add. Also I don't like the empty actions list when people first start with Thunderbird so that's something this would help me out with. I could file a separate bug but wanted to get some input first. Thanks!

(In reply to comment #6) > don't think I really understand what is happening and don't have a test mail to > play with. There is some more technical information in SM bug 462629, along with steps to reproduce and a "broken" mimetypes.rdf example. The problem is two-fold and primarily manifests itself when sending an attachment: - if you receive an e-mail with a wrong association and open the attachment, that wrong association is entered into mimeTypes.rdf and may be used when sending out a message with an attachment of the same file extension (motivates the verify/remove part); - if your operating system doesn't know the association, Thunderbird "guesstimates" the MIME type from its content: an attachment that appears to be text will go out as text/plain, if it contains non-text encoding it gets application/octet-stream as the fallback (motivates the add part). In either case, the user probably won't notice anything until the recipient gets back asking why the PDF was sent as JPEG or while the CAD data comes as a text file. > Is it possible or reasonable for Thunderbird to provide a "canned" set of > common MIME types? The canned version comes from the operating system and may differ in quality between the platforms used. The most commonly used types should be there, the problem occurs with additional file types. Specifically, if the program doesn't properly register a MIME type with its extension (as in the CAD-program example, I think there is a bug somewhere on this), we are sending generic MIME types. Even if the users known exactly that this is type x/y, there is no way provided to set this within Thunderbird. > But when wrong associations are made between file extensions and > MIME types it seems like at association time (while viewing the attachment) > could be a place where we could help more people fix this issue without going > into the prefs. The underlying question is if it makes sense to allow multiple MIME types to be associated with the same file extension, as evidently possible in the PNG-image example shown here and causing an ambiguity anyway. Before adding an entry to mimeTypes.rdf, some warning could show up with the dialog that a different entry for the same file extension exists already, and give the user a choice whether to keep the old definition or to overwrite it with the new one. If you show "PNG Image (.png)" with "image/gif" the user likely would have selected not to add it. In analogy, if no entry exists yet but the presented MIME type contradicts the one suggested by the operating system, this could be similarly marked as "be careful" when the user is presented with the open dialog. I agree that this would be a good addition to safeguard those entries, but nevertheless it should be possible to verify existing entries and remove them if they appear wrong (some people may just hit "Ok" without verifying the presented association). Your suggestion to add back the file-extension column to the type list and to add a "Remove" button to the drop-down menu should certainly work for this purpose.

If I receive an email with an Apple iWork file (Keynote, Numbers, Pages), than I don't see the dialog in which I can pick an application. It is recognized as a Binary File (application/octet-stream) and I only can save it to disk. It's not possible to choose an application. For this case the "Add" button would also be usefull. Than it would be possible to define Numbers for *.numbers files, Keynote for *key files... But I couldn't find a mimetype for Apple iWork files, so I think this could be the main problem here.

A related report is MailNews Core bug 236212 on guessing XML-style attachments as text/html even if they are not. While improving the guesswork of unknown file types is certainly one way to go, it still should serve only as an initial proposal to the user with the ability to add the "real" MIME type if known.

(In reply to comment #6) > > 3) adding an entry from scratch. > I think this has value but I would have to prioritize this below the other > items related to fixing incorrect entries. Fixing the incorrect entries seems > like the greater concern and this more of a feature (as I see it right now). > Unless I'm misunderstanding this, lets spin this one piece off as a separate > bug. I've split this off to bug 503303 as suggested, along with a couple of ideas on how to implement it, and will also create a bug on the sanity-check step before adding a MIME-type association to mimeTypes.rdf per your first part of comment #6. Thus, this specific bug here is now on fixing the regression introduced by bug 446291 of no longer being able to see the associated file extension for an entry and to remove entries which are considered wrong. It looks like the suggested steps of adding back the extension column and adding a "Remove" item to the menu should be feasible in time for the final Thunderbird 3.0 release.

Filed bug 503309 to introduce some safe guards as proposed in comment #7.

Confirming blocking for the remove button entry and assigning to bwinton. Most of the other larger parts of this bug have been spun off to other bugs. I think we can block on getting a remove action added to this piece.

Thanks for the blocking status. While this focuses now on the remove button, it still would help a lot to also add the file extension into a column or as part of the description. Otherwise it's tricky to figure out /which/ entry is wrong and needs to be removed (only indication is mapping back the description to a known file extension then, which may be ambiguous).

(In reply to comment #13) > add the file extension into a column or as part > of the description. Agreed, thanks for the reminder!

Just wanted to make sure that this important detail doesn't get lost. I'm not changing the summary again though. :-)

I haven't added the file extensions yet, but that's in my to-do list. In the meantime, I'ld love to hear whether this was close to what you were thinking of. Thanks, Blake.

Thanks for the patch. I've tested this patch in my own build and this workes perfect. But I think we should include a warning ("Are you sure you want to delete this association" or something), if somebody clicks accidentally to delet the association.

How about labeling it "Delete Entry" rather than "Delete Association"? Shorter and potentially easier to understand than the technical term.

(In reply to comment #16) > I haven't added the file extensions yet, but that's in my to-do list. Okay, here's a patch with the file extensions. (In reply to comment #18) > How about labeling it "Delete Entry" rather than "Delete Association"? > Shorter and potentially easier to understand than the technical term. Done. I'm working on getting a dialog to pop up when you select the delete option, and will post a new patch after that's working. Later, Blake.

Blake, thanks for the screenshot. It appears though that you have replaced the MIME-type field with the file extension, the problem being that you need both in order to figure out that an entry is wrong and should be deleted. The old dialog had a separate "Extension" column, but merging both into a single column should be fine as long as everything is visible.

(In reply to comment #20) > Blake, thanks for the screenshot. It appears though that you have replaced the > MIME-type field with the file extension It does appear that way, but for the entries you see there, there was only one MIME-type, and so it wasn't being displayed. (This was the previous behaviour. I didn't change it.) The code should display one of the following: Portable Document Format Portable Document Format (application/pdf) Portable Document Format (.pdf, .pdfx) Portable Document Format (application/pdf: .pdf, .pdfx) based on whether there is more than one type and/or a set of extensions. I've changed it to display the type if there is one, and attached the screenshot. Let me know what you think. Thanks, Blake.

Yes, that contains now all the information needed to make that judgment. Thus, the example shown in attachment 385786 [details] would have two lines, one with "image/png: .png" and the other "image/png: .gif" which you would delete. Or would it show up as "image/png: .png, .gif" then?

(In reply to comment #22) > Or would it show up as "image/png: .png, .gif" then? Yup, it would all be on one line. Later, Blake.

Makes sense, I had my own example upside-down in comment #22 anyway. There would be two entries "image/png: .png" and the other "image/gif: .png" if the MIME type is the primary key, thus the gif/png mixup easy to identify and to remove now.

Can add a little bit of style to this so the ext doesn't stand out as much. Perhaps andreas could help out here as well. For the screenshot I used the dom inspector to separate out the labels into two, one for the description and one for the extension information. Then applied some graytext color to the extension. The only issue is that on selection the graytext needs some additional CSS so it doesn't look so bad. Also for the delete text I was thinking we could use "Delete Action" instead of "Delete Entry" to be more inline with the items description.

Comment on attachment 394839 [details] [diff] [review] The previous patch, with a confirmation dialog. Works great! See attachment 395102 [details] for comments on styling.

adding andreas for any ideas on comment #26

(In reply to comment #26) > Can add a little bit of style to this so the ext doesn't stand out as much. > Perhaps andreas could help out here as well. I'ld love that. In the meantime, here's what I've come up with. Let me know what you think? > Also for the delete text I was thinking we could use "Delete Action" instead > of "Delete Entry" to be more inline with the items description. Fixed. Thanks, Blake.

Okay, here we go. I would have posted it a lot sooner, but I thought I introduced a really ugly sorting bug, and it took me a while to replicate it on 3.0b3, and then log it as Bug 512191. Thanks, Blake.

Comment on attachment 396164 [details] [diff] [review] The patch for the previous screenshot. only nit is that the delete dialog title should probably be "Delete Action", not "Delete This Action". With that, ui-r+

(In reply to comment #31) > only nit is that the delete dialog title should probably be "Delete Action", > not "Delete This Action". With that, ui-r+ Fixed. Thanks, Blake.

Checked in: http://hg.mozilla.org/comm-central/rev/072d7b84a131