If something (either another program or the user) changes the OS setting for a MIME-type handler, Firefox should respect those settings; the user should not be required to make a separate change in the Firefox UI. Figuring out the best way to mesh this with our registerContentHandler implementation (bug 372441) will require a bit of thinking.
This is a P2, definitely wanted (really, really!) but not a blocker on its own.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: CON-001b [wanted-firefox3]
Are we sure we really want this? Since we can't do 2-way mirroring, the user won't know how changes one place do/don't change in the other place, depending on which place is changed first. I think it would be conceptually cleaner to not do any mirroring at all, but have a really easy to use applications pref pane in Firefox, which is entirely independent from the system settings. Or, we should do perfect 2-way mirroring with the system.
I would suggest to dump the Firefox settings entirely. In my opinion they do not provide any enhancement and have been a hassle to deal with all the time. Furthermore the UI of the relevant preference pane in Friefox is far from self explanatory (at least in Mac OSX), so most normal users don't know how to handle it. In contrast you can change the file type/MIME type - application association in the right-click menu of Finder (Mac OSX's explorer), which is pretty straight forward and easy to do for even the most unexperienced users. Dumping the MIME type settings in Firefox would also save us from mirroring the OS' MIME type repository and thereby bloating the Firefox code. Another option would be IMHO to have an option to enable and disable the Firefox MIME type handling, with disabled as the default status. That way the more experienced users are able to set Firefox MIME types according to their needs, whereas the average user can stick to their OS' MIME type handling.
Whiteboard: CON-001b [wanted-firefox3] → CON-001b
Not shell integration.
Component: Shell Integration → RSS Discovery and Preview
We no longer support registerContentHandler.
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.