414493 - Unable to edit mimetypes.rdf for external applications

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Joe Sabash [:JoeS1]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060804 Firefox/1.5.0.6 (mahowi)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012803 Thunderbird/3.0a1pre ID:2008012803

Clicking on a link in current trunk tbird asks to choose an application.
If you choose to "always do this"
That choice is not editable.

Reproducible: Always

Steps to Reproduce:
1.Click on a link in mail or news
2.An application picker appears
3.Choose an app and choose "always do this"
Actual Results:  
Your choice is remembered, but not editable.

Expected Results:  
External application choices should be editable.

This started with the enhancement checkin for bug 385740
Prior to that Thunderbird used the default application for links.

Comment 1

[Joe Sabash [:JoeS1]]

Attachment: current mimeTypes

current mimetyepes.rdf

Comment 2

[Joe Sabash [:JoeS1]]

Attachment: edit dialog for current trunk

screenshot of ui choices

Comment 3

[Joe Sabash [:JoeS1]]

note that the only thing that displays is the rdf
NC:editable="true"

Comment 4

[Myk Melez [:myk] [@mykmelez]]

I can't reproduce this on Linux (trunk Thunderbird still automatically opens my default browser for links), but my guess is that it's happening because the helper app service on trunk now lets you specify helper apps not only for MIME types but also for protocol schemes, so instead of simply using the default application for the http and https schemes, the service now prompts you to pick an application.

In conjunction with that change, we built a new Applications prefpane that lets you configure helper applications for both protocols and schemes.  But while the changes to the helper app service are shared by multiple applications, that prefpane is currently Firefox-only.

If we wanted to revert Thunderbird to the previous behavior, it should be possible to do so.  Alternately, if we wanted to enable scheme configuration in Thunderbird, we could copy the Applications prefpane over or move it into Toolkit and have Firefox share it with Thunderbird (and perhaps also SeaMonkey) from there.

cc:ing Thunderbird, Toolkit, and Firefox principals for their thoughts.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Erm, s/protocols and schemes/MIME types and protocol schemes/.

Comment 6

[Phil Ringnalda (:philor)]

I suspect that getting to comment 0's behavior requires some more steps, like you need to have run into bug 392403 before it was fixed by whatever fixed it, probably bug 397906, and then perhaps you also need to have made some particular choice then (if I'm reading that mimeTypes.rdf correctly, it thinks both that it should use the system default and that it should be using Thunderbird to open http links from Thunderbird).

That said, I'm pretty sure the apps prefpane is DO WANT, if for no other reason than "it's always a really bad idea not to follow Fx for things around shared code."

Comment 7

[Sanjay Bijani]

I think this belongs here, if it doesnt let me know.

I used to have Illustrator CS, upgraded to CS3. In Thunderbird, the link to open AI files remained the same. I wanted to edit it, but it did not show up in the Attachment Settings (Prefpane?)
I looked in the mimeTypes.rdf, manually changed the location of the .exe and the double clicking works now... but .ai file handling does not show up in the settings box.

Comment 8

[Matěj Cepl]

Actually, I can reproduce this pretty well with thunderbird-2.0.0.17-1.fc10 on Linux (Fedora/Rawhide) as seen in https://bugzilla.redhat.com/show_bug.cgi?id=470169

Comment 9

[Przemyslaw Bialik]

Related / dupe of Bug 311138

Comment 10

[Wayne Mery (:wsmwk)]

still fails with beta 4?

Comment 11

[Ronald Killmer]

Tb trunk builds with the newer Options > Attachments design fails to show any of the helper associations. With Tb2 we have an additional MIME Type Col, normally hidden, yet User can add to display MIME types that trigger Tb handling.

Manual editing of the *.rdf is not a desirable method for Users to try fixing wrong associations. Also there is an inconsistency where we have UI for editing Plugins through the Addon Manager. Letting Tb use the Windows Registry can be problimatic. A bad association for Real Player got stuck in the *.rdf with no way to correct it after Real was stripped from the Vista system.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

While it's useful to know the state of affairs on Tb trunk builds, what we really need to know is the state of affairs on Tb 1.9.1 (i.e. 3.0*) builds.

Comment 13

[Wayne Mery (:wsmwk)]

Joe, thoughts on going forward?

Comment 14

[Ronald Killmer]

Unless Joe has some indicators of a current issue with the rapid release TB13 build, I suggest we close this bug.  TB is picking up the same App setting tools used by the matching FF rapid release which (as of this date) are more versatile than what we had 4 years ago.

I think that future issues should be reported against core if their code regresses UA consumers such as TB.

Comment 15

[rsx11m]

Actually, Thunderbird's implementation is on top of Firefox's as it added back the "remove" functionality per bug 501163 and also shows associated MIME types and file extensions. There are spin-offs from that bug for adding an association explicitly (bug 503303), and to prevent picking up invalid associations by opening an attachment with a wrong content type (bug 503309).

Regardless of the remaining limitations of the current helper-applications management and the settings dialog, the entries provide a "use other" menu item to re-associate any wrong application with another one, which - as my understanding - was Joe's main motivation to open this bug.

Comment 16

[Joe Sabash [:JoeS1]]

Yeah, I think we should put this one to bed now.