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.

current mimetyepes.rdf

screenshot of ui choices

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

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.

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

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."

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.

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

Related / dupe of Bug 311138

still fails with beta 4?

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.

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.

Joe, thoughts on going forward?

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.

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.

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