This is an installer initiative to provide facility for Win32 plugin vendors. Gecko Embedding Clients running on Win32s ought to use this Reg. key schema. For the purposes of this discussion, a "Product" is a Gecko Embedding Browser (e.g. a user-agent). Hence, "Product x.y" would be version x.y of the "Product." These are the current suggestions: 1. A per Product key will be used. 2. This key will have the following structure: HKEY_LOCAL_MACHINE\Software\Mozilla\Product x.y\Extensions\ 3. All Gecko Embedding Browsers will follow this structure. 4. Extensions will contain information about both Plugins as well as Components. Value and Value-data pairs inside ..\Mozilla\Product x.y.\Extensions\ will resemble: Components="C:\..\components\ Plugins="C:\..\plugins\ 5. Similar key structure is to be copied into HKEY_CURRENT_USER in case reads are not possible from HKEY_LOCAL_MACHINE for permissions purposes (Win2k?) or write purposes. 6. Plugin vendors will be evangelized to check for this Reg. Key schema so that they know what keys to look under to find Gecko embedding browsers. They can, for instance, enumerate the 'Mozilla' key to plugin path information for Gecko embedding browsers. Caveats: Note that Product x.y contains implicit product versioning information in the key name. This is a requirement to discover versioning information so plugin vendors know what version they are installing into.

The values were intended to be paths rather than single directories. To maximize sharing, it is suggested that later installs look at the paths of earlier installs and re-use existing paths as much as possible. For example, if several products are installed that are completely plugin compatible then there should really only be one directory containing all plugins for that compatible set of products. The way this would work is the first one would set its path, the second would copy the path of the first, etc. The burden of determining compatibility is on the product's installer (and would usually be based on known product/version information at the time the product was shipped.)

selmer, could you clarify the distinction you're making between paths and single directories? note that, for example, C:\Mozilla\bin\components and C:\Mozilla\bin\plugins are where components (and components.reg) and plugins go respectively in Mozilla. A user-agent like Netscape 6 has: C:\program files\Netscape\Netscape 6\plugins (and components). Installs of Gecko Embedding browsers under the Mozilla subkey will mention the directories vendors ought to look for to install components and plugins, so that the product can detect them upon startup. I'm not sure that as of now Gecko embedding browsers will be able to share paths in this way, although this would be ideal. Anyone jump in and correct me if I'm wrong, please.

Copying about a gazillion Sun folks on this bug, since it has impact on the Java Plug-In.

Note: this is very similar to bug 66840 Mozilla fails to detect installation of JRE plugin which was just fixed.

Note that this bug is a sort of "work-order" (for want of better words) hopefully to be in 0.9.1 for helpful Reg. keys for plugin vendors so that they are aware of Gecko embedding browsers. The common codebase means vendors can expect Mozilla plugins to work in Gecko embedding browsers. This gives a useful detection mechanism, whereas Bug 66840 details how JRE couldn't be found (and solution). Nominating mozilla0.9.1

I've opened [Bug 78150] [RFE] Include OJI plugin installation path in plugin scan to see if we can modify plugin code to pickup the Java plugin until their installer can be updated.

Paths vs Directories: The plugins/components value should be a Path rather than a single directory. This allows plugins to search multiple places to find a valid plugin. The capability is important as it allows each embedded app to both re-use existing stuff and also have it's own non-shared stuff (for instance if it's not compatible with those other apps for some reason.) Syntactically, the values for these keys should be "<dir>;<dir>;...". Semantically, these directories should be searched from left to right looking for the plugin or component (depending on which key we're talking about.) Embedded app installers should examine the existing set of directories when building their path to maximize the sharing.

Information from Samir about Mac Installer issues: The Mac "knows" where to find applications based on information stored in the desktop database at install or download time. Every application vendor must register their unique four character code, aka the creator code, with Apple. Subsequently if a document associated with an application is double-clicked, the creator code of the document is consulted by the OS, then the desktop db is searched for the last installed version of the application and the document is handed to the application by sending the Open AppleEvent to the app. Since this information exists in the desktop db, plugin vendors can also use it to figure out where the various versions of mozilla and netscape are installed. Once they get the mac alias (which is simply mac's representation of a file location), they can query version info on the app itself. Vendors can query the Mac desktop database using the Desktop Manager routines: <http://gemma.apple.com/techpubs/mac/MoreToolbox/MoreToolbox-511.html#HEADING511-69> It is possible to use PBDTGetAPPL() to query all instances of a particular application. The creator codes for mozilla and netscape are 'MOZZ' and 'MOSS', respectively.

My patches are for the windows platform, and will be checked in along with bug 77981 's patch.

So our embedding vendors will need to apply a similar patch to custimized to their products?

Peter, this is correct. Parties who embed Mozilla will be encouraged to write these keys to the registry (Win32) in a manner similar to what ssu's patch does.

Arun, then maybe it would be wise to save this patch or post it publicly somewhere, perhaps in the embedding pages. Also, what about making Gecko a little smarter by making it self-heal? Could we move this code to startup, or even perhaps in nsPluginHost's constructor, such that if these keys are missing, we add them at that time thus eliminating the need for embedding vendors to do this? What do you think?

Peter, I agree with posting this patch publicly. The problem with solving this "identification" problem at the Gecko level is how does Gecko determine "Product x.y"? Note that a key idea behind this (pardon the pun) is we're adding some version info. into the keys. So, IF as part of the embedding APIs Gecko can figure out its embedding product, and you can obtain complete product and version info., then you can make a case for moving the patch into Gecko core code. I'm CC'ing Judson Valeski, so that he can shed more light on this problem.

Arun, looking at the patch, it's rather quite simple. The key is created in this form: Software\Mozilla\$ProductName$ $UserAgentShort$ Geting the UserAgent string in plugin land is trivial and I think we can get the product name as well from the service manager. nsSpecialSystemDirectory can return our program path. What else am I missing? I can probably plug in the code to plugins if someone can furnish some working Win32 API code for this logic. Already this bug has 2 patchs, one for NS and one for Moz. Seems to me we are duplicating a lot of code and giving people more work to do.

Please be aware that the patches are for the native installers only. The duplication and the vars used are only for the installer build process. This would mean that the installer will need to be manually sync'ed up against whatever values the embedded code generates/sets. I'm sure the build process could be fixed to retrieve the value(s) used by the main build. However, this is not that big of a problem since the versions are not changed frequently.

Perhaps the installer shouldn't even be involved in creating these keys so there is nothing to sync up. Is there a preWhere are these variables comming from ($ProductName$ $UserAgentShort$)? They are native installers, but isn't there eventually some C code that asks some kind of component or service for the values?

I would love it if the installer did not have to do this. The only instance that I can think of that the installed might need to do this is: 1) user installs the embedded product 2) but does not run the "just installed" product 3) installs 3rd party plugins that attempts to locate gecko embedded products 3rd party plugins will not be able to locate the "just installed" product because it has not been at least run once. Is this a valid scenario to worry about? Regarding where the variables come from, there's no "service" when the native installer is running. This is because there is no xpcom yet. Remember, this is a small "stub" installer. So the variables are hard coded in the installer's build process, which is seperate from the main client's build process.

Oh...I see the problem. That is a valid situation that will break. But at least for Mozilla and Netscape, dot we startup the browser after install anyway for activation or component registration? I forget the exact steps that happen. What if we put the code in a small external file that both the fatty XPCOM browser can use and the lean and mean installer can use? It could be built with Gecko, perhaps using #defines for the variables? Can the stub installer read the prefs? Probably not with no nsIPref service :( We can tell embedders that browser will fill in this registry info, but it must be started after install. If they choose not to start, they must call this c function. Now this is starting to sound complicate for solving that one case. Perhaps it's just better to use the patches already in this bug. I just thought it may be a cleaner solution if the browser did the key creation as I don't trust leaving it up to the embedding installer.

> 3rd party plugins will not be able to locate the "just installed" product > because it has not been at least run once. Is this a valid scenario to worry > about? Yes, we do need to worry. What if we package these 3rd party plugins with the native installer itself? Those packages (e.g. RealPlayer, Flash) are installed before the browser and Gecko are launched at the end.

Actually, I can easily think of this scenario happening. OEM manufatures will want to preinstall products onto their systems without having to run all the products at least once. They will likely install everything at once. If the installer does not register these keys, then any plugin app that gets installed afterwards will not find the gecko embedded product. As for tyring not to hard code the useragent, I can easily modify the installer's build process (written in perl scripts) to parse the user agent file. FYI: if the decision is made in the future to have each gecko embedded product update the windows registry at startup, please take into consideration that it will fail under Win2k for a non-admin-accessed user when updating the HKEY_LOCAL_MACHINE (even though we might be updating HKEY_CURRENT_USER as well - which should be okay).

patch checked in. I just realized that I will have to move this code into the browser.xpi's install.js file. I had forgotten about the case where the user goes to the Netscape's smartupdate site and simply installs the .xpi files without using the native installer. I'll leave this bug open until the move is done. However, people dependent on this bug can start tesing using the native windows installer.

this is such a nasty issue :-/. one thing to note: currently we don't enforce UA string format. So, when we talk about the "Product" token being accessible via nsIHTTPHandler, it actually might not be. depending on the resolution of this proposal, perhaps it will be a requirement that the do this to get plugin functionality. this is not something that can be done lightly though, sniffers have grown to look for certain UA strings, and asking embedding applications to modify their traditional format is often not doable.

patch to move the registry settings from the native installer to the browser.xpi 's install.js is with bug 56538. I'll will mark this fixed when that bug is fixed.

fixed.

I am reopening. A further piece of implementation that's necessary based on plugin vendor feedback is to add a "bin" subkey giving the path to the *.exe (executable) that spawns the browser process on Win32s: HKEY_LOCAL_MACHINE\Software\Mozilla\Product x.y\bin\ 1. 'bin' will contain the path to the Mozilla based browser executable: e.g. the Value and Value-data pair will be: PathToEXE="C:\Program Files\Netscape\Netscape 6\netscp6.exe" 2. All gecko embedding browsers implement this so that there's a uniform "quick and dirty" way to find the path to the executable. Many plugin installers invoke the browser upon installation to complete registration, etc. This gives them a way to find the executable.

r=sgehani for patch ids={39950,39951} contingent upon resolving the cvs conflict in patch id=39950.

rs=mscott

a=chofmann branch and trunk

the last two patches have been checked in.

gemal - are you going to verify this? If not, pls set the qa contact to bmartin@netscape.com

PathToEXE is not created under HKEY_LOCAL_MACHINE\Software\Mozilla\Mozilla 0.9.2\bin\