use new APIs in Vista to register file and protocol handlers (installer)

RESOLVED FIXED in Firefox 2

Status

()

defect
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: beltzner, Assigned: rstrong)

Tracking

({verified1.8.1.2})

2.0 Branch
Firefox 2
All
Windows Vista
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.1 -
blocking1.8.1.2 +
blocking-firefox2 -
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Fx 2.0.0.1][vista] depends on bug 354005, )

Attachments

(6 attachments, 5 obsolete attachments)

68.10 KB, image/png
Details
111.98 KB, image/png
beltzner
: ui-review+
Details
93.50 KB, image/png
beltzner
: ui-review+
Details
24.43 KB, patch
rstrong
: review+
moco
: review+
Details | Diff | Splinter Review
24.44 KB, patch
Details | Diff | Splinter Review
95.80 KB, image/jpeg
Details
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.

Comment 1

13 years ago
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.
Whiteboard: .5d

Comment 4

13 years ago
(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.
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.
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
blocking for new strings
Flags: blocking-firefox2+
Keywords: late-l10n
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!

Comment 10

13 years ago
(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.

Comment 13

13 years ago
(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>
;)

Comment 14

13 years ago
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.

Comment 16

13 years ago
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.
Posted patch checked in - string change (obsolete) — Splinter Review
String only patch to get this in before the string freeze
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #233555 - Flags: review?(beltzner)
Attachment #233555 - Flags: approval1.8.1?
Whiteboard: .5d → [at risk][post beta]
Target Milestone: Firefox 2 beta2 → Firefox 2
Comment on attachment 233555 [details] [diff] [review]
checked in - string change

r,a=me for branch and trunk.
Attachment #233555 - Flags: review?(beltzner)
Attachment #233555 - Flags: review+
Attachment #233555 - Flags: approval1.8.1?
Attachment #233555 - Flags: approval1.8.1+
New string checked in to trunk and MOZILLA_1_8_BRANCH. Leaving open for the remaining work.
Attachment #233555 - Attachment description: string change → checked in - string change
Attachment #233555 - Attachment is obsolete: true

Comment 20

13 years ago
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....

--> unblocking, will cover this for a Fx2 dot-dot release.
Flags: blocking-firefox2+ → blocking-firefox2-
Whiteboard: [at risk][post beta] → [Fx 2.0.0.1]

Updated

13 years ago
Blocks: 352420
Summary: use new APIs in Vista to register file and protocol handlers → use new APIs in Vista to register file and protocol handlers (installer)

Updated

13 years ago
Flags: blocking-firefox2- → blocking-firefox2?
Posted image SPAD screenshot (obsolete) —
It appears to be working properly but I do think this needs more testing before and after it lands.
Posted patch patch - almost there (obsolete) — Splinter Review
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
Posted patch Patch rev2 (obsolete) — Splinter Review
This should be enough for the installer. If you used the previous patch there will be left behind reg keys and name / value pairs.
Attachment #238621 - Attachment is obsolete: true
Posted image screenshot 1
beltzner, this is as we discussed.
Attachment #238977 - Flags: ui-review?(beltzner)
Posted image screenshot 2
Attachment #238590 - Attachment is obsolete: true
Attachment #238591 - Attachment is obsolete: true
Attachment #238978 - Flags: ui-review?(beltzner)
Comment on attachment 238977 [details]
screenshot 1

purty!
Attachment #238977 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 238978 [details]
screenshot 2

purty!
Attachment #238978 - Flags: ui-review?(beltzner) → ui-review+
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.
Attachment #238976 - Flags: review?

Comment 34

13 years ago
Ok - we are cutting 1.8.1 in minutes so this will have to defer for a 2.0.0.1 branch.
Flags: blocking-firefox2? → blocking-firefox2-
Attachment #238976 - Flags: review? → review?(sspitzer)
Comment on attachment 238976 [details] [diff] [review]
Patch rev2

r=sspitzer
Attachment #238976 - Flags: review?(sspitzer) → review+
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.
Attachment #238976 - Attachment is obsolete: true
Attachment #239228 - Flags: review+
Checked in to trunk
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
Flags: blocking1.8.1.2+
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.

Updated

13 years ago
Whiteboard: [Fx 2.0.0.1] → [Fx 2.0.0.1][vista]
Whiteboard: [Fx 2.0.0.1][vista] → [Fx 2.0.0.1][vista] depends on bug 354005
Depends on: 354005
Duplicate of this bug: 368135
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.

Comment 44

13 years ago
(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.

Comment 46

13 years ago
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.
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)?
You need to log in before you can comment on or make changes to this bug.