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.

The required entries are not all managed by the installer... there are several that will need to be added to the browser's set default browser code. I can do the installer piece in under half a day and I suspect the remaining piece to be about a day. I opened Bug 339306 for the browser piece and since I suspect I am going to be the long pole for beta 1 it would be a good thing if someone else took on that bug.

(In reply to comment #1) > The short list of things that need to change: > A related Vista change is registering so that a user can opt for Firefox as the default Browser in the reserved Start Menu slot. (This action ought to take place as a side effect of explicitly making Firefix the default browser from the FF menus.) Due to changes in the API, the former XP code no longer works.

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

Heads up... we are going to need a couple of localized strings for this. I will be submitting them tonight so if we can fix this bug the strings are already in the tree.

blocking for new strings

beltzner, I need description text for the app as is done for IE in this screenshot. Thanks!

First pass, I'd like to get some comments from cbeard and pkim. I'm trying to get the description to a point where it answers "what is this and why would I want to set it as the default". when --enable-branding is on ..: Firefox 2 Mozilla Corporation Firefox is an easy to use web browser that lets view your web pages quickly and safely, protecting you from spyware and unwanted pop-up windows. With features like integrated search and tabbed browsing, Firefox helps you efficiently manage your online life ... it even checks your spelling! when --enable-branding is off ..: Bon Echo 2.0a1 mozilla.org Bon Echo is an easy to use web browser that lets view your web pages quickly and safely, protecting you from spyware and unwanted pop-up windows. With features like integrated search and tabbed browsing, Bon Echo helps you efficiently manage your online life ... it even checks your spelling!

(In reply to comment #9) > > when --enable-branding is on ..: > Firefox is an easy to use web browser that lets view your web pages quickly and > safely, --> "that lets YOU view"? Same for when --enable-branding is off

To simplify this just use brandShortName for the app name string and just come up with one string instead of writing the description twice.

(In reply to comment #11) > To simplify this just use brandShortName for the app name string and just come > up with one string instead of writing the description twice. Someone once told me he preferred it when I used the actual name "in situ", and since I had to redo the name/published for the branded/non-branded cases ... but yes, it would be &brandShortName;. And yes, Patrick, I was missing a "you". Thanks.

(In reply to comment #12) > And yes, Patrick, I was missing a "you". <italian accent>And i was a-missin' a-you too"</italian accent> ;)

We're going to want this description and the use of the full name vs. the short name to be consistent with the brand architecture working currently in progress. Let me check on status and respond ASAP.

(In reply to comment #12) > Someone once told me he preferred it when I used the actual name "in situ", and > since I had to redo the name/published for the branded/non-branded cases ... > but yes, it would be &brandShortName;. In that specific situation entity and %S were being swapped (e.g. &brandShorName and %S) and it wasn't always clear that %S would be brandShortName or brandFullName so I asked to just provide the name. In this case I asked for brandShortName so we don't end up with a different description string except for brandShortName since the localized string is not different based on --enable-official-branding... just the defines in defines.nsi.in change. It is also simpler in thus case.

Please use below: Firefox delivers safe, easy web browsing. A familiar user interface, enhanced security features including protection from online identity theft, and integrated search let you get the most out of the web.

String only patch to get this in before the string freeze

Comment on attachment 233555 [details] [diff] [review] checked in - string change r,a=me for branch and trunk.

New string checked in to trunk and MOZILLA_1_8_BRANCH. Leaving open for the remaining work.

it would be better if this bugs was closed and a new bug for remaining work so it shows up on testing and localization radars, or open a new bug for the string change.... rob said he would do the later and put the late-l10n keyword on it....

I opened bug 349042 per comment #20

--> unblocking, will cover this for a Fx2 dot-dot release.

It appears to be working properly but I do think this needs more testing before and after it lands.

This needs the patch in bug 352424 to work fully Things left to do: 1) gopher doesn't have an urlmon.dll reg entry though registering urlmon.dll creates it. Need to find out how the OS behaves without it. If you run into problems testing this run regsvr32 %SystemRoot%\System32\urlmon.dll 2) We need a different location to store the Capabilities reg key since there can only be one (yes, just like Highlander) StartMenuInternet registry key... or can there be more than one? Will more than one work with other OS's? 3) Need to come up with a better string for the app to use to register as default or teach Software Update about this or possibly both. 4) I believe the app is still setting the classes reg keys when running on Vista - if it is it shouldn't. 5) Get some sleep and dream about the things I've overlooked.

Almost forgot, to test this use -enable-official-branding for now... this is needed to make a string used by the installer and a string used by the patch in bug 352424 to be the same.

(In reply to comment #25) > ... > 2) We need a different location to store the Capabilities reg key since there > can only be one (yes, just like Highlander) StartMenuInternet registry key... > or can there be more than one? Will more than one work with other OS's? Doesn't matter... since we need to add protocol handler reg keys and these won't be unique there is no value in trying to set a unique StartMenuInternet key. > 4) I believe the app is still setting the classes reg keys when running on > Vista - if it is it shouldn't. Actually, we will have to set a different set of keys

This should be enough for the installer. If you used the previous patch there will be left behind reg keys and name / value pairs.

beltzner, this is as we discussed.

Comment on attachment 238977 [details] screenshot 1 purty!

Comment on attachment 238978 [details] screenshot 2 purty!

Comment on attachment 238976 [details] [diff] [review] Patch rev2 Everyone that has worked with this code besides myself is away at present. >Index: browser/installer/windows/nsis/installer.nsi ... >@@ -33,17 +33,17 @@ > ; Set verbosity to 3 (e.g. no script) to lessen the noise in the build logs >-!verbose 3 >+;!verbose 3 Ignore... this won't be commented out. >@@ -393,19 +396,16 @@ ... >- ; The previous installer adds several regsitry values to both HKLM and HKCU. >- ; We now try to add to HKLM and if that fails to HKCU >- Ignore... this won't be removed.

Ok - we are cutting 1.8.1 in minutes so this will have to defer for a 2.0.0.1 branch.

Comment on attachment 238976 [details] [diff] [review] Patch rev2 r=sspitzer

The original patch needed the ifexec support added to it from bug 353089. I went over this addition with sspitzer and got a verbal r= for this addition.

Checked in to trunk

We want this on branch as soon as possible, but Vista support is not a 2.0.0.1 blocker at this time. marking wanted1.8.1.x

This is a blocker for 2.0.0.2, but there's no approval request for a patch. Is the trunk patch appropriate or do we need something different?

I'll land this on branch when / if approved with the patch in bug 354005 since it includes additional required changes.

Using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a2pre) Gecko/20070130 Minefield/3.0a2pre, this looks good. The only thing that is weird in the attached screenshot is the fact that Firefox is listed instead of Minefield in every instance except the Start Menu. Perhaps this is a minor issue, but wanted to note it. Will verify on the branch once it lands.

(In reply to comment #43) > Created an attachment (id=253408) [details] > File Association screenshot > Using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a2pre) > Gecko/20070130 Minefield/3.0a2pre, this looks good. The only thing that is > weird in the attached screenshot is the fact that Firefox is listed instead of > Minefield in every instance except the Start Menu. Perhaps this is a minor > issue, but wanted to note it. Will verify on the branch once it lands. To fix the description check what the friendlyTypeName is listed as for instance for HTTP look at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\http\FriendlyTypeName as an example The entry you want to update would be the browser specific http registration so something like HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Mozilla\MineField.Url.HTPP\FrienlyTypeName That should fix the description To fix the name of the app look at the file description for the exe of the browser.

What Ed said except to add that this was intentional initially since it can be a PITA to update HKLM keys via Software Update... we have that mostly fixed now so I'll look into fixing this.

rstrong: Are you going to log a new bug for the remaining issue Marcia found in comment #43? Of is this something you are looking to fix now and will track in this bug?

jay, that is an extremely simple thing to change (only one line changed) now that we can request elevation... I'll add it to the fix for elevation.

Since the majority of the community is not running nightly 1.8.1.x branch builds I would like to hold off on changing the names for the protocol and files handlers... we've got enough going on already and we can just address this on the trunk if it is decided we should.

fixed on the branch.

verified on the 1.8 branch using Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.2pre) Gecko/2007020703 BonEcho/2.0.0.2pre. I verified by confirming that when you select "Bon Echo" that a proper description is shown, and I checked the protocols and they look good too. Adding verified keyword. rstrong - one puzzling thing, why does Firefox not show up in the Set Program Access and Other Defaults (Under both Custom and Non-Microsoft)?