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
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.
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"
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?
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
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?
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.
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.
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
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.
minusing edt0.9.4. This is an embedding application installer issue.
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.
just to clarify. the *dtx.x.x nomination is indeed formalized, there just isn't a netscape commercial release branch targeted at this point :-).
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.
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.
reassigning to dan
GeckoVer of the branch rv: is actually ok granularity, no one really cares about the exact date.
Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are niminated, but not yet plussed.
reassigning to curt
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.
nsbeta1+ issues for Win Installer
adt3 per triage
topembed+ per EDT triage.
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.
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
Reassigning myself as QA Contact so I can track the rtm bugs
Created 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.
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.
>+ 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.
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.
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 on attachment 89437 [details] [diff] [review] Patch 1 >+Key=Software\Mozilla\$UserAgentShort$ Most important, this should be "$ProductName$ $UserAgentShort$", not plain "7.0"
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.
Created attachment 89651 [details] [diff] [review] Patch 2 (for Mozilla)
Created attachment 89652 [details] [diff] [review] 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 on attachment 89652 [details] [diff] [review] NS browser.jst Patch 1 sr=dveditz
Comment on attachment 89654 [details] [diff] [review] Mozilla browser.jst Patch 1 sr=dveditz
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 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.
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.)
Checked into ns trunk. Waiting for a= to check into mozilla trunk. Waiting for adt approval to check into branch.
--> reassign to curt
adding adt1.0.1+ for ns fix. Please check this into the branch today.
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.
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.
Verified code fix
"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.
Thanks Dan! Verified on build 2002-07-11-08-1.0.
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.
marking fixed per triage. let's test for this one see if it is still a problem.
verified registry settings for Mozilla (1.2.1/1.3.a and 1.3.b) and Netscape 7.01