462629 - Cannot access MIME-type and file associations in new Helper Applications pane

Status: NEW

(SeaMonkey :: Preferences, enhancement)

Description

[rsx11m]

This is a follow-up on bug 417590 comment #4, raising valid concerns on some missing functionality in the application pane adopted from Firefox. Since those were no further addressed in that bug, I'm filing this report here so that the issue doesn't get lost.

In general, the redesigned Helper Applications pane is more intuitive and "less technical" for the average user, lacks however a clear display of MIME types and file extensions. While this may be fine for the browser-only Firefox application, it inherits a problem frequently seen in Thunderbird: Wrong MIME types are associated with file extensions simply by opening an attachment of an incoming message exhibiting this error, and are subsequently used for sending attachments with the same file extension. While this could have happened with the old Helper Applications as well, the problem was thus far of lesser impact as such inconsistencies could be identified and resolved in the more detailed old pane, providing edit and delete functions.

As suggested in bug 417590 comment #6, MIME content types and associated file extensions should be displayed and editable in the Application Details dialog, thus accessible in the advanced dialog part, and also a dedicated "delete" functionality introduced. The remark in bug 417590 comment #5 to simply switch to "always ask" will remove the action, but not any file association, thus won't be effective for the problem described here.

Comment 1

[rsx11m]

Attachment: Test case: Wrong MIME definition from received message

To demonstrate how easy it is to accidentally create a wrong entry from an incoming message and that it will override any system settings for future attachments sent, here some steps to reproduce:

1. Create a file with an extension known by the operating system (e.g., .xls) but not yet included in the Helper Applications list,

2. attach this file to a message you compose, either send it to yourself or store as draft,

3. edit the message in the mailbox and change (for this example) application/vnd.ms-excel to application/vnd.buggy,

4. after rebuilding the summary file, open the attachment of that message,

5. confirm to open the file with its default MS-Excel, check "Always use this application".

6. Now, create a new message with another ".xls" file,

7. verify that it was sent with "Content-Type: application/vnd.buggy",

8. try to identify and delete the wrong entry in Edit > Preferences > Browser > Helper Applications.

[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081030 SeaMonkey/2.0a2pre]

You can skip 1.-5. when using the attached RDF file. Note that while the cause for the problem is on the receiving end, its impact becomes only visible when sending an attachment. With the new Helper Applications pane, mimeTypes.rdf has to be cleaned up manually as the entries can no longer be edited.

Comment 2

[Matthias Versen [:Matti]]

The new helper application Panel is in my eyes near useless.

I have a testcase from the german Firefox Forum.
this is the situation:
OS: Windows
File-type: .m3u, assigned in windows to vlc. 
.m3u itself is a playlist in text-format

You have a local html page with several links to local m3u files, some tools generate such a page.
If you click on the File, Seamonkey (and FF) shows this file as text-File because the windows entry for this file is missing a mime-type.

You can't add a new entry for m3u with a audio/x-mpegurl in the helper app panel to get it working.
I had to put a m3u file on a webserver and open it with SM, save the decision permanently, go to the helper app Panel and change it to "always ask" to get it working. An alternative way would be to open the windows registry editor, search somewhere in the registry for m3u and assign a mime-type to it.

I opened the helper app panel the first time after months and it's now useless for basic tasks of an advanced user.

Comment 3

[WADA:World Anti-bad-Duping Agency]

FYI.
Because Seamonkey has Bug 471027 in addition to Thunderbird, wrong mime definition in mimeTypes.rdf is very easily generated. (See Bug 471027 Comment #10)
1. Compose a mail, attach ".xls" file, Send Later, Move the mail to a folder
2. View the mail and Delete the attachment, 
   -> Double-Click the deleted attachment -> Open dialog -> Select action and OK
   -> mimetype:text/x-moz-deleted for ".xls" is generated in mimeTypes.rdf

Note: After that, chain mail of Content-Type:text/x-moz-deleted for ".xls" is easily produced by users themselves, if mail recipients execute above step 2.

Comment 4

[rsx11m]

After Thunderbird has now adopted the new FF-like Helper Applications dialog as well, with the same problems as described here, there is bug 501163 covering
the issue on that end. While they are not exactly the same, obviously solving one bug would benefit the other.

Comment 5

[rsx11m]

A patch for Thunderbird has been checked in this morning to add a "Remove" option to the context menu of the Helper Applications, as well as providing more details on matched file extensions. This should be feasible for porting to the SeaMonkey preference pane.

The "Add" functionality was split off to bug 503303 without any proposed patch at this time.

Comment 6

[Karsten Düsterloh]

JFTR: that was bug 501163.

Comment 7

[Robert Kaiser]

New feature, not wanted on 2.0 after feature freeze any more, might still be nice to have on a later release though.

Comment 8

[rsx11m]

I'm putting this back on the nomination list for 2.1, at least some of the code should be usable from the Thunderbird 3.0 implementation to get started.

Comment 9

[Manuel Reimer]

The patch for thunderbird allowes deleting entries, which is a good start. I'll put this on my task list to port this to SeaMonkey, if noone else does it. In the same list, there should be placed an "Edit" button to edit and see the extensions, defined for this MIME type.

Comment 12

[rsx11m]

Per bug 803832, the user there had to clean up /multiple/ wrong entries for the same MIME type that have been picked up from incoming messages. Notwithstanding that bug 503309 needs to be fixed to help preventing this issue in the first place, cleaning up wrong associations from the UI rather than by manually editing the mimeTypes.rdf file would have substantially simplified the procedure.

Comment 13

[zetka]

I agree strongly to apply the possibility to delete wrong entries for SeaMonkey too.