This is a spin off for the browser part of Bug 336469 (e.g. asking user if they would like the app to be the default, etc.)... from bug 336469: Windows Vista provides new APIs that allow applications to register file and protocol types more easily, and with new capabilities that allow the application to describe itself so that the file association UIs can provide meaningful information to the user. We should be using these new APIs as soon as possible when we detect that the target system is Windows Vista. I'll attach a whitepaper and reference URLs shortly. The short list of things that need to change: 1. The installer always needs to write FireFoxHTML Progid (the current installer only does it if FF is selected to be the default) 2. The installer needs to Create new ProgIDs specific to its protocols (for instance FireFox.Url.HTTP and FireFox.Url.HTTPS) 3. The installer needs register Firefox with the new default programs schema ( this is a schema written to HKLM at install time) 4. Rev the code that FF uses to claim\check defaults to use the new API set. I have a cookbook for implimentation but it is to large to upload into this bug. This documentation isn't currently up on MSDN but it should be part of the beta SDK. See URL (http://people.mozilla.com/~beltzner/vista-program-defaults/) for the documentation. The .png files are screenshots of Vista with the .txt registry keys installed, and the .doc is the cookbook.

...Interesting, One (big) question, how does this affect when a <user> installs say, Chatzilla for Firefox, that uses the irc:// and ircs:// protocols. Also say a web-based e-mail system develops an extension, could it then register the mailto protocol with Firefox, (essentially telling it to forward the url to its own system). Or does the Vista syntax (currently) require _all_ Defaults settings (options) to be instantiated at install time?

When you install chatzilla or some other add-on to firefox you will want to update FF registration for IRC and IRCS if it does not already contain it those protocols. My understanding of how chatzilla works is that firefox owns the default shellexcute behavior for IRC and then it delegates to chatzilla if it sees it installed.

re: c#2. Well yes Firefox owns the reference and delegates to Chatzilla, but the code to set the irc handler is *in* Chatzilla, (which means that in any installation Firefox won't know it supports the irc protocol until post CZ Install. And I am also adamant that we should not pretend (by claiming) Firefox supports schemas that "may" not be installed, and likely are not on most users set-ups. see: http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/chatzilla-service.js#288 (the area around there).

I checked this out on XP and FF 1.5.0.2 and chatzilla and I am not sure there is a problem. On XP if you go to the run dialog or command line and try to launch IRC: it fails. Or if you click on a IRC:\hyplink from a mail message. IF chatzilla doesn't care about being directly invoked from places in the windows shell then there isn't an issue. FF will always correctly delegate to chatzilla from within FF and Cahtzilla will always be able to invoked from its shortcut. If these are sufficient then there is no work for chatzilla. Does that make sense?

In the vista case, imho, if we have an extension which uses a given protocol, we should _not_ delegate to the protocol unless Vista claims it should, (if Vista has another app as "use the IRC protocol" by default) The obvious exceptions to this rule are things that make sense to _always_ load with Firefox, htm/html, svg?, xhtml, in-app loaded jpeg, etc. If we always assume the user wants CZ when the OS has very good mechanics to support user-choice in this regard, why abandon it? My concern is, does the OS allow for extensions to add to the list for Firefox, (or even "as the extension" with description and handler pointing to Firefox?)

From a comment in bug 336469... The documentation for implimentation is on MSDN now http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_new_vista/default_programs.asp

Marking [mustfix] due to a comment I read that states: "Changes are needed just to make the former code to "make Firefox my default" browser work under Vista, since sections of the registry are now write protected" Until we get a confirmation that this isn't true, we're gonna need this for Vista compatability. Robert: is this the sort of thing we can fix in the installer, or does it need fixes to the application itself? I'm trying to determine if it's something we could get in Firefox 2.0.0.1 (since Vista won't be out until then ..)

(In reply to comment #7) > Robert: is this the sort of thing we can fix in the installer, or does it need > fixes to the application itself? I'm trying to determine if it's something we > could get in Firefox 2.0.0.1 (since Vista won't be out until then ..) No, the setting as the default app (e.g. default, browser, default mail client, default calendar, etc.) need to be handled by the app.

there fix required fix is 2 parts: 1. Have the installer write the new registration keys for vista (this bug) 2. Rev the code FF is using to chack and set itself as default post install (this is bug 336469) cheers, Ed

We're not going to block Fx2 on this, we will get this into a point release before Vista ships, likely 2.0.1 (or 2.0.0.1, depending on how we do the versioning for security/stability releases).

This will probably require changes to software update to support modifying / adding registry keys for Vista.

Note: currently the app adds the protocol handlers which doesn't make sense in Vista so we'll probably do this in the installer. Since gopher isn't supported by IE we are going to have to add both the protocol handler as the app does today and an app specific protocol handler that is used to set the app as the default for the protocol... or we could remove it.

It appears that our app still has a ddeexec hack where it removes the ddeexec key on shutdown and adds it back on startup... this is bad / wrong on so many levels. If the user is not admin it can't do this, if the app crashes it can't remove it, etc. This really should be removed if for no other reason than consistent behavior for admin and non-admin users. I suppose it could be doing this under HKCU for non-admin users but iirc it doesn't

*** This bug has been marked as a duplicate of 352424 ***

Clearing blocking flag.