Closed Bug 13784 Opened 25 years ago Closed 24 years ago

[FEATURE] Mime Type/File Extension/Application Service Registration

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jefft, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta2+]Exception Feature2d)

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?
Component: Browser-General → XPApps
Priority: P3 → P1
Target Milestone: M12
Ugh. This is really part of the whole "URL dispatching" nightmare too.
Move to M13.
Updating QA Contact.
Assignee: don → davidm
Summary: Need MimeType/FileExtension/Application Service Registration to work in harmony → [FEATURE] Mime Type/File Extension/Application Service Registration
David ...
Blocks: 10958
OS: Windows NT → All
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
QA Contact: paulmac → shrir
Blocks: 24206
Target Milestone: M13 → M14
Moving to M14 ...
Keywords: beta1
PDT-
Whiteboard: [PDT-]
assign to stop the spam
Status: NEW → ASSIGNED
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.
Keywords: beta2
Moving to M15.
Target Milestone: M14 → M15
Blocks: 10802
Moving what's not done for M15 to M16.
Target Milestone: M15 → M16
Keywords: beta1
Whiteboard: [PDT-] → 2d
Keywords: nsbeta2
gagan thinks this is fixed now..is it?
Whiteboard: 2d → [NEED INFO]2d
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.
Whiteboard: [NEED INFO]2d → [nsbeta2+][5/16]2d
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.
Whiteboard: [nsbeta2+][5/16]2d → [nsbeta2+]Exception Feature2d
Blocks: 41197
M16 has been out for a while now, these bugs target milestones need to be updated.
Reassign to mscott
Assignee: davidm → mscott
Status: ASSIGNED → NEW
No longer blocks: 24206
This is really just a different flavor of Bug #38374 which has been implemented already.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.