77244 - Installers need to create Win32 Reg. key schema that Gecko Embedding browsers can follow

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Arun Ranganathan]

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.

Comment 1

[selmer (gone)]

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.)

Comment 2

[Arun Ranganathan]

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.

Comment 3

[drapeau]

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

Comment 4

[Peter Lubczynski]

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

Comment 5

[Arun Ranganathan]

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

Comment 6

[Peter Lubczynski]

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.

Comment 7

[selmer (gone)]

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.

Comment 8

[Arun Ranganathan]

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.

Comment 9

[Sean Su]

Attachment: patch #1 (ns tree)

Comment 10

[Sean Su]

Attachment: patch #1 (moz tree)

Comment 11

[Sean Su]

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

Comment 12

[Peter Lubczynski]

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

Comment 13

[Arun Ranganathan]

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.

Comment 14

[Peter Lubczynski]

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?

Comment 15

[Arun Ranganathan]

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.

Comment 16

[Peter Lubczynski]

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.

Comment 17

[Sean Su]

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.
 

Comment 18

[Peter Lubczynski]

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?

Comment 19

[Sean Su]

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.

Comment 20

[Peter Lubczynski]

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. 

Comment 21

[Daniel Veditz [:dveditz]]

> 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.

Comment 22

[Sean Su]

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).

Comment 23

[Sean Su]

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.

Comment 24

[Judson Valeski]

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.

Comment 25

[Sean Su]

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.

Comment 26

[Sean Su]

fixed.

Comment 27

[Arun Ranganathan]

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. 

Comment 28

[Sean Su]

Attachment: additional patch for the last requirement (ns tree)

Comment 29

[Sean Su]

Attachment: additional patch for the last requirement (moz tree)

Comment 30

[Samir Gehani]

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

Comment 31

[Sean Su]

Attachment: patch to the ns tree that resolves the conflict.

Comment 32

[Scott MacGregor]

rs=mscott

Comment 33

[chris hofmann]

a=chofmann branch and trunk

Comment 34

[Sean Su]

the last two patches have been checked in.

Comment 35

[lchiang]

gemal - are you going to verify this?  If not, pls set the qa contact to
[e-mail]

Comment 36

[Henrik Gemal]

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