MimeType/FileExtension service registration has been addressed by NECKO but not the Application Registration. I wonder who is doing this and when it can be done. I need this for opening mail attachments feature.

don?

Ugh. This is really part of the whole "URL dispatching" nightmare too.

Move to M13.

Updating QA Contact.

David ...

I don't know what "MimeType/FileExtension service registration has been addressed by NECKO but not the Application Registration" means but it scares me.

setting correct QA contact

Moving to M14 ...

PDT-

assign to stop the spam

To be clear, what we need here is 2 things: 1. Our current mime service has a hard-coded mapping from file extensions to mime types. We need an extensible mapping that is persistent. (This will be used primarily for files coming off the net.) 2. We need to also hook into the platform-specific mappings for file types (type/creator codes for mac, registry for windows, file extensions for unix). (This will be use primarily for files coming off the local disk.) One of these mappings needs to take precedence -- probably the second. Please correct me if I'm misunderstanding the problem here.

Marking beta2.

Moving to M15.

Moving what's not done for M15 to M16.

gagan thinks this is fixed now..is it?

If it is fixed, I'd like to be pointed to it, please. I'm facing a similar issue: http://www.sourcexchange.com/WishDetail?wishID=227 I would like to know whether these things should be run with xpfe/appshell or xpcom/appshell. Thanks in advance.

Current status. There is code to read and write an XML file. What still needs to be done is 1) automatically read in that file after selecting a profile 2) install the above file when a new profile is created. 3) Figure out where the profile manager should be getting its data from I was hoping to do 1+2 today but I spent way to much time getting a build to work.

Why an XML file? Is there a separate bug which covers reading and writing the Windows Registry?

we're going to need to serialize to disk for unix anyway, it makes sense to me to have our own persistance be a an XML file across platforms, with OS specific read throughs.

Putting on [nsbeta2+][5/16] radar.

What jud said. There is an interface for dealing with platform native mime mapping. The initial IC implementation for the mac is done. I thought there was a bug for windows but I can't find it.

Please note that in addition to helper output applications, there is now an official W3C spec and some new infrastructure (thanks to Eric Pollmann!) for helper input applications: http://www.bovik.org/devup-petition

On exception list for PR2, removing 5/16...giving [nsbeta2+]Exception Feature status.

M16 has been out for a while now, these bugs target milestones need to be updated.

Reassign to mscott

This is really just a different flavor of Bug #38374 which has been implemented already.

When I click on the 'new type' button in Prefs|Navigator|Helper Apps and register a new application, after I press the OK button, a message window titled "Helper Application Exists" and saying "A Helper application already exists for the MIME type".Do you want to replace it?". After I press OK the window titled "New type" still remains open and does not close unless I press "cancel" or "X" . Also, my application is not listed in the helper app list but it works as I mentioned in bug 38374. Should I open another bug for that and mark this verif?Thnx

There's a separate but owned by Ben Goodger for implementing the UI for the prefs panel for helper apps. I'd suggest adding your comments to that bug or asking Ben if he wants new ones for problems with the prefs panel. I was using this bug to track the back end implementation of launching helper apps which is done.

marking this verified. I added my comments to bug 10958.

A new column, "input or output or both" needs to be added for: http://www.pollmann.net/data/salsman_audio_extensions.patch Please see also: http://www.bovik.org/devup Cheers, James