109402 - [viewpoint] Add extra info to plugin registry key on windows

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Peter Lubczynski]

In the windows registry, each Mozilla embeddering vendor have a product key with
subkeys plugin vendors use for locating the browser. Because the version of
Gecko is starting to become important for plugin compatibility, we need to relay
this information at installer time. I suggest we include the buildID of Gecko in
each bin subkey under each product. Something like:
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Netscape 6 6.1\bin] Gecko BuildID = 20011109

Comment 1

[Judson Valeski]

yikes. binding a version number to a registry key is a constraint w/ non-trivial
ramifications for XPI, and other update mechanisms. Basically, anyone updating
the Gecko dist will have to rev the build number. on the surface this seems like
a bad idea.

Comment 2

[TaylorToddK]

Peter is going to come back and touch up the versioning issue.  I think the 
Mozilla version information will be more and more important as Mozilla 
continues to add new technology to its foundation.  For vendors to be aware by 
Mozilla versioning whether or not a browser supports XPInstall or XPCOM 2.0 
will be allow them to supply the most optimized version of their product.

An additional key for the Windows registry that needs to be touched up is the 
PathToExe. As the value of this key is only the absolute path to the product, 
it does not neccessarily give the vendor enough information to open a URL with 
that application.

For dedicated browsers, simply calling the browser executable with the URL 
argument appended is sufficient.  However, for applications that have another 
primary role but that embed a browser, simply passing the URL as an argument 
may not be enough information for the application to understand this is 
information intended for the browser. Each application should be able to 
provide to the vendor the format in which they want the URL passed, in a manner 
that is uniform from the vendor's perspective and still allows the application 
to use its own proprietary format for relaying the content to its browser.

The solution would be an additional key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Netscape 6 6.1\bin] OpenURL = 
**application provided string with %1 placeholder for URL**

The application provided string would be a formatted string to launch the 
application with the URL.  The vendor would replace the placeholder (the %1) 
with the URL and then have the operating system execute the command.

To clarify by example, Netscape may have:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Netscape 6 6.1\bin] OpenURL=c:\program 
files\netscape\netscape.exe %1
but an embedded browser application, such as Real Player, may have:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Real 8\bin] OpenURL=c:\program 
files\Real\real.exe -browser"%1"




 

Comment 3

[Peter Lubczynski]

Todd's right. We need a format string in the window registry tied with actions
because each embeder may use different command line arguments. This is seperate
from the version info.


For version info, actually, using the buildID isn't a good idea and it's not
tied to the source. I think using the mozilla version may be a better idea.
Plugin vendors' installers would then be able to tell if an embedded browser
supposed the same plugin features as mozillaX. Maybe like a key under bin:
mozver=mozilla0.9.1?

Comment 4

[TaylorToddK]

I like MozVer for a value name, but the mozilla prefix should not be used in 
the data value. It seems redundant since this value will appear under the 
Mozilla key and MozVer already implies it is a mozilla version.  I prefer
MozVer=0.9.1

Comment 5

[Judson Valeski]

so, if the mozver = X, and "the" (define "the" for me here, which moz dist is
"the" one, considering there can be multiple on disk) binary mozilla
distribution gets updated by a 3rd party (either expanding functionality w/ new
components, or fixing (security hole for example) code), does the mozver get
bumped (that would imply that there is no connection between the "mozver" key
and the mozilla milestone), and if so, how do the installers (XPI, native,
other) know what the versioning scheme is to do the bumping?

Comment 6

[Peter Lubczynski]

No, this would not get bumped in that case. If an embedder chooses to include a
"mozver" key in the windows registry, they are advertising that they are
compatible with mozilla[X]. A security patch or enchancement probably won't
conflict with being compatible with mozilla but it will be up to the embedder's
installer or updater to write the version.

Comment 7

[TaylorToddK]

There are additional keys that should be added to the windows registry 
information. 

The root key should not have to be parsed for a vendor to extract the program 
name and version information.  From the perspective of the Windows registry 
mechanics, this key is simply a unique identifier a vendor uses while 
enumerating the mozilla based browsers that wish to receive third party add-
ons.  There may be products embedding mozilla that have multiple instances of 
the same version installed on the machine. In this case, the application will 
have to provide a unique identifier for each individual instance, resulting in 
a key that will not necessarily make sense in the current "ProductName 
Major.Minor" format. Therefore, the root key should only serve as a unique 
identifier in the registry. Vendors looking for additional product information 
should look to the addition values provided by the application:

Root Key/Default Value - This will serve as the user-friendly name of the 
product that the vendor uses when presenting any UI to the end user.

Root Key/"Product" Value - The name of the product.

Root Key/"Version" value - The product's version.

Root Key/"PreferredApp" value (optional) - There are vendor installers that 
need to run the application's browser to complete the installation.  If an 
application has multiple instances installed on the machine, and running any 
one instance will complete the installation for all, this value will idenitfy 
the Root Key of the application to use.  The presence of this value informs the 
vendor that the application of every root key does not have to be launched to 
complete the installation.

Root Key/Bin/"OpenURL" value - This is the format key specified in my above 
comment (Additional Comment #2).  Appending a URL to the Root/Bin/"PathToExe" 
does not guarantee that a browser will be launched by the application and this 
is a bug for existing embedders.

Comment 8

[Chak Nanga]

Here's what was decided on this issue from the meeting of Dec 13, 2001.

1. Add the following new String Values to the existing
[HKEY_LOCAL_MACHINE\Software\Mozilla\Productx.y] key:

"Product" - The name of the product
"Version" - The product's version
"DisplayName" - User friendly name of the product

For Ex: We should have the following for, say, Netscape 6.3:

[HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 6 6.3]\Product=Netscape 6
[HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 6 6.3]\Version=6.3
[HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 6 6.3]\DisplayName=Netscpape 6.3

2. Add the new [shell/open/command] subkey to the existing
[HKEY_LOCAL_MACHINE\Software\Mozilla\Productx.y\ bin] key

The (Default) value of the above newly added subkey should be set to a
StringValue which is the path to the EXE(value is the same as the current
"PathToExe") followed by "%1"

For Ex: We should have the following structure:

[HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 6 6.3\bin\shell\open\comand]

whose (Default) value will be set to:

"<PathToExe>" "%1"

where, <PathToExe> is the value of our current "PathToExe" string value.

Mozilla and Netscape installers will need to be modfd. to start adding the above
mentioned new keys/values asap[CS installers will be doing the same].
The sooner we can get these changes in the better, since we can start
evangelizing this to the plugin vendors.

Hi Syd : Currently this bug is set to "Future". What are your thoughts on
getting this into an upcoming milestone?

Thank You

Comment 9

[Arun Ranganathan]

This should *absolutely* be targetted, since embedding partners want to
evangelize these very simply added Reg. Keys to plugin vendors.  I'm following
Asa's nomination process and adding the keywords.
Note that I'm adding edt0.9.4 merely to put this on the embedding radar, since
this is an *installer* bug and therefore and embedding installer ought to do
this work.

Comment 10

[Judson Valeski]

minusing edt0.9.4. This is an embedding application installer issue.

Comment 11

[Arun Ranganathan]

Since adt* nomination process hasn't been formalized for "Netscape" branded
branches, I'm also adding nsbranch to get next release train attention.  If
someone knows better nomination way, please change this.

Comment 12

[Judson Valeski]

just to clarify. the *dtx.x.x nomination is indeed formalized, there just isn't
a netscape commercial release branch targeted at this point :-).

Comment 13

[Arun Ranganathan]

Following the teleconference on Jan 4 '02, here's what we've decided to do with
respect to the versioning information metadata in the Win32 registry.  Read bug
118272 for an understanding of how actual user-agent strings will change.

We'll write an additional String Value to indicate the Mozilla branch from which
the code is taken for each application.  It will be an application specific
value called GeckoVer, and will reside under the application's key (which is
under the Mozilla subkey).  It will store String Value data:

"GeckoVer" -- The tagged branch build version identifier of Gecko that the
product uses.

Example -- using Chak's examples for a hypothetical Netscape 6.3, this would
look like:

[HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 6 6.3]\GeckoVer=0.9.4.2

This suggests that the tagged (hypothetical) branch that Netscape 6.3 will use
may look like this in CVS: MOZILLA_0_9_4_2_RELEASE

The additional ".2" at the end of the 0.9.4 suggests further "revving" of the
0.9.4 branch, and thus is intended to distinguish it from other variants of the
0.9.4 family.  For example, a hypothetical embedder, CompiSwerve, may have a
GeckoVer indicating a revision beyond 0.9.4.2, with additional changes, and thus
this could be:

[HKEY_LOCAL_MACHINE\Software\Mozilla\CompiSwerve]\GeckoVer=0.9.4.3

This suggests that the CVS tag could be: MOZILLA_0_9_4_3_RELEASE 

The goal is to give third party vendors installing components an idea of the
published Mozilla branch that the application is based on.  The GeckoVer String
Value is in addition to the Product, Version, and DisplayName String Values and
exists at the same level as these, under the Product specific subkey.

Comment 14

[Daniel Veditz [:dveditz]]

Nominating and clearing "Future" target since recent activity in the bug
indicates someone expects us to implement this. Have at it, guys.

Incidentally I'd push for something that matches the Gecko pulldate in the user
agent string since a "milestone" marker gives a pretty broad target. "0.9.4"
could mean a lot of things with a great range of fixes up to the "0.9.4.1"
point. I'm not even sure what 0.9.4.2 would mean since mozilla.org hasn't
released one yet. A GeckoVer of 20010904.124, on the other hand, would mean
something built from source pulled 124 days into the Sept 9 2001 branch (i.e.
something pulled from the 0.9.4 branch on 1/6/2002). In the extremely unlikely
case of a branch off a branch this scheme could be extended to whatever extent
necessary: 20010904.124.37, or 20010904.124.37.8

I know it's kinda ugly, but it's compact, meaningful, and specific. 0.9.4.2
doesn't mean a whole lot until mozilla.org releases one, and meanwhile there'd
be a lot of different development and/or beta builds out there claiming to be
that release.

Comment 15

[Syd Logan]

reassigning to dan

Comment 16

[Daniel Veditz [:dveditz]]

GeckoVer of the branch rv: is actually ok granularity, no one really cares about
the exact date.

Comment 17

[Syd Logan]

Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are
niminated, but not yet plussed.

Comment 18

[Syd Logan]

reassigning to curt

Comment 19

[Arun Ranganathan]

yay, thank you whoever nominated this nsbeta1 and plussed it :-)  Just to
clarify: the publicly available CompuServe beta which uses Gecko writes these
keys in the Win32 Registry.  So both future Netscape branches and future Mozilla
milestones ought to follow-suit, so we can have a consistent "methodology."  I'm
on the hook to update http://mozilla.org/projects/plugins/install-scheme.html
with the information in this bug and will get to it ASAP.  Curt (et al.) feel
free to ping me directly with any questions.

Comment 20

[Grace Bush]

nsbeta1+ issues for Win Installer

Comment 21

[Syd Logan]

adt3 per triage

Comment 22

[Dave Barrowman]

topembed+ per EDT triage.

Comment 23

[Arun Ranganathan]

Please don't nsbeta1- this bug!  Some vendors will not be well-served by doing
this.  What's in this bug is the up-to-date spec. which will eventually replace
http://mozilla.org/projects/plugins/install-scheme.html . The Compuserve beta
does this, and ViewPoint rely on it.  So please let's make sure our installer
does it also.  It's easy to do.

Comment 24

[Arun Ranganathan]

From ViewPoint's update, it becomes very obvious why GeckoVer string in registry
is necessary.  So it didn't get to make the beta train, but there's an RTM train
and this ought to be on it.

Hi Arun,
we have again reviewed the reasons why we need the regkey. The main 
reason is to prevent installation of the Viewpoint Media Player (VMP)
into Gecko based browsers, which don't support the fixes we reported 
and worked on with Peter L. and his team for and after the CompuServe
release.

The digest of all of the problems is that the Gecko plugin architecture 
is in constant flux and VMP (windowless plugin) has a lot of 
requirements on consistency and stability of the API to function 
properly. 

The current VMP installer, searches for all installed compatible 
browsers and tries to install the player into their plugin directories. 
In order to prevent crashing and or,  bad user experience, we made the
decision, *not* to install into versions of Gecko based browsers,
which don't satisfy the API requirements. The registry key
is the discriminator for the installer. If it does not exists
we don't install, although the two may be completely compatible. 

If the key cannot exist, we would like to offer and discuss with 
you another (I think simple) solution. We could include the VMP 
installer into the browser installer. At that point we would avoid the 
search and therefore the regkey all together. 

The compatibility is implicitly indicated by the fact of inclusion

Comment 25

[K'Trina Medina]

Reassigning myself as QA Contact so I can track the rtm bugs

Comment 26

[Syd Logan]

taking

Comment 27

[Joseph Elwell]

Attachment: functionally, this is what needs to happen. Haven't been able to build an installer that works to test though.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 88946 [details] [diff] [review]
functionally, this is what needs to happen. Haven't been able to build an installer that works to test though.

>RCS file: /cvsroot/mozilla/xpinstall/packager/windows/browser.jst,v

This would need to go in both the Mozilla and Commercial versions
of browser.jst

>@@ -26,6 +26,10 @@

This is the wrong place, move it down to registerMainKeys()

>+  subkey  = "SOFTWARE\\$CompanyName$\\$ProductName$";

In this case we want the shared Gecko keys, not the product specific
keys (you'll see both sets in the registerMainKeys function)
    subkey = "SOFTWARE\\Mozilla\\$ProductName$ $UserAgentShort$"

We already create that key, so you could just add the value
string in the appropriate place.

>+  winreg.setValueString(subkey, "GeckoVer", "1.1a+");

You've got the version hardcoded, but you added script to try to
calculate it. Which way are you going? If you leave it here we
need to make sure this gets onto the build team's list of things
they have to update for each release.

>Index: wizard/windows/builder/build.pl

build.pl is a developer tool, if you get something here you'll
need to pass it into makeall.pl and make sure the build team updates
their script to also pass the value into makeall.pl. So putting it
into makeall.pl or makejs.pl might be more direct (assuming you're
not going to just hardcode the value as you did above).

All these scripts have both Mozilla and commercial versions. Yes, it
sucks, and one of these days we'll fix bug 22062 and not have to do
all this dual maintenance.

>+    if (/general.useragent.misc", "rv:(.*)"\)\;/)

Someday someone's going to forget to leave the space between the
pref name and the value, or put in two spaces. the regexp should
handle potential valid changes in the future. "general.useragent.misc.*rv:"
is probably good enough, but if you want to put in the quotes and comma
then use \s* in between.

Customized build can put more optional comments in the .misc field
and be perfectly valid. The rv: field is semi-colon delimited in
this case and then followed by arbitrary junk. For example:

  pref("general.useragent.misc", "rv:1.0.0; pr0n-enhanced");

so perhaps (.*) should be ([^; "]*) or something on those lines.

>+sub geckover

This kind of thing is already done in makejs.pl -- you could just add
a line to an existing section once you've got the value you want.

Comment 29

[Joseph Elwell]

>+  winreg.setValueString(subkey, "GeckoVer", "1.1a+");

>You've got the version hardcoded, but you added script to try to
>calculate it. Which way are you going? If you leave it here we
>need to make sure this gets onto the build team's list of things
>they have to update for each release.

woops, I must have done the diff after I ran the script. the 1.1a+ should read
%MOZILLATREETAG%

dan: the rest of your comments are useful but as it turns out Syd says he has a
patch on another bug to fix this already. I'm not sure which bug number that is.
But that obsoletes my patch.

Comment 30

[Curt Patrick (gone)]

The fix got checked in for Netscape Commercial (both trunk and branch) in the
fix for the bugscape bug #17054.  I'll extract the pertinent code from that fix
and attach a patch for mozilla to this bug.

Comment 31

[Curt Patrick (gone)]

Attachment: Patch 1

Comment 32

[Daniel Veditz [:dveditz]]

jelwell's approach was more appropriate (but see my review comments). If 'Update
Notification' leads to an XPinstall-only upgrade then the GeckoVer will not get
updated, whereas it would if the registration were done in the browser.xpi script.

His scriptable attempt to get the GeckoVer from another checked-in file makes
updating the version automatic, although he put the code into the wrong script.
On the other hand if the Gecko version ever diverges from the browser version
then using the rv: value in the UA could be the wrong thing to do, but that's in
the future.

If you want to go with a hand-maintenance scheme, has this been added to the
list of "things to do every release"? btw, where *is* that list? Anyone else
trying to ship a mozilla version will want access to it.

A four-digit version doesn't fit the spec. Maybe if we branch from the branch
it'll be right, but that extra .0 implies a branch that hasn't ocurred. Also it
really should be version 1.0.1 now (1.0.0 was ok for PR1).

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 89437 [details] [diff] [review]
Patch 1

>+Key=Software\Mozilla\$UserAgentShort$

Most important, this should be "$ProductName$ $UserAgentShort$", not plain
"7.0"

Comment 34

[Curt Patrick (gone)]

After reading through all the comments and talking with dveditz here is what I
plan to do:

- Add the registry code into browser.jst (instead of config.ini, as the patch
has it)
- Have the build team add this to their release checklist, and make sure they
publish that checklist where others can make use of it.
- Open a bug about automating this.  We are too close to release now to twiddle
with the build scripts more than we have to, but we definitely want to make this
part of our automation as soon as possible.

Comment 35

[Curt Patrick (gone)]

Attachment: Patch 2 (for Mozilla)

Comment 36

[Curt Patrick (gone)]

Attachment: NS browser.jst Patch 1

That isn't the right patch.  Here is the NS one, though, while I figure out
where the mozilla one went.

Comment 37

[Curt Patrick (gone)]

Attachment: Mozilla browser.jst Patch 1

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 89652 [details] [diff] [review]
NS browser.jst Patch 1

sr=dveditz

Comment 39

[Daniel Veditz [:dveditz]]

Comment on attachment 89654 [details] [diff] [review]
Mozilla browser.jst Patch 1

sr=dveditz

Comment 40

[Syd Logan]

Comment on attachment 89652 [details] [diff] [review]
NS browser.jst Patch 1

r=syd, but please make sure that there was not some implied importance to the
presence of 4 digits. Arun originally had me do the 4 digit format, not sure if
there is some requirement on the plugin for that e.g. we barf their parser or
something if the last digit is missing.

Comment 41

[Syd Logan]

Comment on attachment 89654 [details] [diff] [review]
Mozilla browser.jst Patch 1

r=syd, but please make sure that there was not some implied importance to the
presence of 4 digits. Arun originally had me do the 4 digit format, not sure if
there is some requirement on the plugin for that e.g. we barf their parser or
something if the last digit is missing.

Comment 42

[Curt Patrick (gone)]

I created bug #154934 to track the need to generate the GeckoVer value at build
time.

Kyle, could you make sure that maintenance of this GeckoVer values gets added to
the release checklist.  (BTW, if it isn't already, that checklist really should
be made available publicly so other Mozilla builders can benefit from the work
you've done.)

Comment 43

[Curt Patrick (gone)]

Checked into ns trunk.  
Waiting for a= to check into mozilla trunk.
Waiting for adt approval to check into branch.

Comment 44

[Syd Logan]

--> reassign to curt

Comment 45

[scottputterman]

adding adt1.0.1+ for ns fix.  Please check this into the branch today.

Comment 46

[Curt Patrick (gone)]

Checked into ns branch and marked fixed1.0.1, but I cannot check it into the
mozilla tree without a= approval so I cannot really resolve this bug.

Comment 47

[Curt Patrick (gone)]

Well, come to think of it, I guess I can check this into the mozilla trunk
without a=, and probably nobody cares about it on the mozilla branch anyway.  So
lets call this fixed.

Comment 48

[K'Trina Medina]

Verified code fix

Comment 49

[Daniel Veditz [:dveditz]]

"Verified code fix" is inappropriate for this one, please verify this in your
windows registry. The code uses ugly replacement variables and we've already had
to fix one mistake made that way.

First make sure there are no keys under
HKEY_LOCAL_MACHINE\Software\Mozilla\Netscape 7.0 (uninstall probably will do
this, but double check), then install and check the GeckoVer key that's actually
installed.

Curt: people probably do care about this on the mozilla branch since that's
intended to be used for a long time by other vendors, and the evangelism group
is pushing that plugin providers use this key.

Comment 50

[K'Trina Medina]

Thanks Dan! Verified on build 2002-07-11-08-1.0.

Comment 51

[Curt Patrick (gone)]

I trust that Dan knows whereof he speaks so I'm reopening this for mozilla
branch.  I'm not sure what the right way of taking this off of adt radar is so
I'll let someone who knows fix the keywords appropriately.

Comment 52

[Syd Logan]

marking fixed per triage. let's test for this one see if it is still a problem.

Comment 53

[Grace Bush]

verified registry settings for Mozilla (1.2.1/1.3.a and 1.3.b) and Netscape 7.01