Closed Bug 293548 Opened 16 years ago Closed 16 years ago

Provide windows registry install location for extensions


(Toolkit :: Add-ons Manager, enhancement)

Windows XP
Not set





(Reporter: darin.moz, Assigned: darin.moz)



(Keywords: fixed1.8)


(2 files)

Provide windows registry install location for extensions.

See proposal here:
Depends on: 292981
Target Milestone: --- → Firefox1.1
Hmmm, Couldn't this instead just be supported within firefox or the extension
manager without having to even come near the registry? Also to give devs on
other platforms the same benefit in the process by maybe having a 'developer'
button that links to a local folder that could be enabled/disabled via that
windows prefs?

fig 1. - extensions window ( install button added because it's desperatly needed
on *nix builds)

| Extensions                                                 _ = x |
| +--------------------------------------------------------------+ |
| | icon   |  extension 1                                        | |
| | -------------------------------------------------------------| |
| | icon   |  extension 2                                        | |
| | -------------------------------------------------------------| |
| |                                                              | |
| +--------------------------------------------------------------+ |
|                                                                  |
| [install] [uninstall] [update] [options] [developers] get more!  |

fig 2. - dev window ( path to working folder + list extensions in that folder.
if the folder is empty, present options for creating a new working extension
folder and generate a basic rdf for them with guid to start from.)

| Develop Extensions                                         _ = x |
|                                                                  |
| Some brief disclaimer explaining this window and what it's used  |
| for. Along with a link back to a page with more details about    |
| how to make full use of it.                                      |
|                                                                  |
| Path : _C:\Application)_Data\Users\Bill.C\Documents\Ext_ [open]  |
|                                                                  |
|    Current Extensions in this folder:                            |
| +--------------------------------------------------------------+ |
| | icon   |  extension 1                                        | |
| | -------------------------------------------------------------| |
| | icon   |  extension 2                                        | |
| | -------------------------------------------------------------| |
| |                                                              | |
| +--------------------------------------------------------------+ |
| Create a new Extension for this folder:                          |
|                                                                  |
| Generate new UID and brief RDF installation file for your new    |
| FireFox extension. (link : learn more}                           |
|                                                                  |
| UID : _______________________________________________ [ create ] |
|                                                                  |
| Author : ____________________________________________            |
|                                                                  |
| Extension Name : ____________________________________            |
|                                                                  |
| Version : ___________________                                    |
|                                                                  |
|                                            [ create ] [ cancel ] |

This would probably not only create a valid beginners extension with a proper
UID (save the UMO team some headaches, or add to them). But it would give those
a chance on other platforms to do the same, without having to fork this feature
two different ways. I'm guessing the options could easily instead be stored in
the firefox configuration settings instead of storing them in a registry key.
The point of a registry based install location is to make it really easy for a
third-party installer (perhaps an MSI) to be created that installs an extension
for firefox.  This will enable people to install extensions even when firefox is
not present on the system.
Ack! Thanks for clearning that up, Darin, I totally misunderstood the purpose of
this, sorry :) I thought the wiki was describing actual extensions not what
could be termed as 'plugins' (ie: quicktime, flash, etc..) in seperate locations.  

However what I described above could also be useful for after 1.1 or further
down the line developer-wise. Linking to a seperate secondary directory and
registering it with firefox without the need to repackage a theme or extension.
Just an idea that's totally seperate from this.
plugins already have a way to be found via the registry. so it sounds to me like
this bug really is about extensions.
Yes, this bug is only about extensions.  BTW, I also want to support extension
install locations outside the app folder and profile folder.  For example, it
might make sense for there to be a ~/.mozilla/firefox/extensions/ folder where
extensions (or text links to them) could be installed.  Same goes for other
platforms.  The registry based install location is just nice because it fits
really well with third-party installers on Windows.  It's really easy to write a
MSI that sets a reg key ;-)
Attached patch v1 patchSplinter Review
Ok, here's the patch.  It includes a variety of bug fixes as well as the
addition of a new nsIInstallLocation implementation.

I'll comment more once I have a chance about what bugs are exactly fixed.
Attachment #183449 - Flags: superreview?(beng)
Attachment #183449 - Flags: review?(benjamin)
Changes included in this patch:

 * Make nsIInstallLocation include all of the methods required to implement
   an install location.  Some of the methods for staging files to be installed
   were left off based on a discussion I had with Ben.

 * Modified to function even when a specified install location
   appears not to be defined.  This allows us to properly uninstall items that
   may be installed in a location that has disappeared.  This is an edge case,
   but it is still something we should support given the pluggable nature of
   install locations.

 * Fixed a minor bug with DirectoryInstallLocation that caused all instances
   of that object prototype to share the same _locationToIDMap.

 * APP_GLOBAL install location should use PRIORITY_APP_SYSTEM_GLOBAL as its 
   priority instead of PRIORITY_APP_SYSTEM_USER.

 * The isDirty parameter to EM.start is not needed.  This patch makes it be
   unused, but the parameter should really just be removed.  I will do that
   once bsmedberg's patch that touches that same interface lands.

 * Make sure that EM.start calls _finishOperations whenever there are 
   pending operations.  This helps avoid EM getting into situations where
   it thinks it needs to restart the app more than once.

 * Make EM._checkForFileChanges much smarter about dealing with the same
   extension ID appearing in multiple install locations.

 * Make EM._finishOperations clear any OP_NEEDS_ENABLE and OP_NEEDS_DISABLE
   flags on items in the StartupCache.  This solves the bug where disabled
   extensions never get updated in the UI to say that they are actually 
   disabled.  They just keep getting reported as will be disabled next time
   even though they are truly disabled.

 * Fixed a major bug in EM._finishOperations that caused it to not handle
   multiple operations of the same time at once.  The solution: iterate
   over |items| in reverse order.

 * Make EM._finalizeUninstall always require a restart.  This is necessary
   for extensions at least and may in fact not be necessary for themes.
   I haven't tested themes :-(

 * Fix EM._getActiveItems to correctly not return any items that are
   disabled.  This is necessary now that we clear that OP_NEEDS_DISABLE
   flag from the StartupCache.  So, the code checks the datasource which
   is the only place where we record information about disabled extensions
   (aside from maybe groking that info from extensions.ini).

 * Make installation and upgrade code bypass "staging" code if the required
   properties are not defined by the item's install location.

 * Make EM._finalizeUninstall not try to delete an extension that is managed
   independently! :-)

Finally, the only other change is the addition of the WinRegInstallLocation,
which depends on my patch from bug 292981.
> * Fixed a major bug in EM._finishOperations that caused it to not handle
>   multiple operations of the same time at once.  The solution: iterate
>   over |items| in reverse order.

s/same time/same type/
Requesting blocking on this for 1.8b2.  The group of people inclined to
investigate the developer preview release are probably heavy extension users,
and this cleans up a number of extension issues (per comment #7) that while
mostly cosmetic are fairly annoying for daily use and testing.
Flags: blocking1.8b2?
Blocks: 294101
Comment on attachment 183449 [details] [diff] [review]
v1 patch

Whoops, I thought I had marked r+ a while ago: only one nit -
getDescriptorFromInstallLocation changed, but the documentation didn't.
Attachment #183449 - Flags: review?(benjamin) → review+
This is a reduced version of darin's patch, with my nits fixed: it has the EM
cleanup bits, which are required to fix the startup regression in bug 294150;
it does not have the #ifdef XP_WIN load-from-registry bits. I would really
really like to land this for 1.1a.
Attachment #183737 - Flags: approval-aviary1.1a1?
Blocks: 294150
benjamin, chofmann gave a= for the winreg API.  can we instead go for the full
patch here then?
> it has the EM cleanup bits, which are required to fix the startup regression
in bug 294150

benjamin: i scanned the patch real quick... which EM bits are you talking about?
 what was needed in addition to my patch to fix the startup regression?
> benjamin: i scanned the patch real quick... which EM bits are you talking about?
>  what was needed in addition to my patch to fix the startup regression?

Nothing more was needed, your patch fixed the problem. My patch was only "the EM
cleanup bits of darin's patch, not the windows-registry bits". The only stuff I
added was

1) hand-merged your patch with the safe-mode landing
2) my review nit about the comment on getDescriptorFromInstallLocation
3) removed an extraneous unused "var uncoveredItems" in _finishOperations
4) removed the extra param from nsIExtensionManager.start

Landing your version is fine.
OK, probably best to add back the #ifdef XP_WIN parts to the patch you created.
Comment on attachment 183737 [details] [diff] [review]
v1 patch with the registry bits removed
Attachment #183737 - Flags: superreview+
Attachment #183737 - Flags: approval-aviary1.1a1?
Attachment #183737 - Flags: approval-aviary1.1a1+
Attachment #183449 - Flags: superreview?(beng)
Closed: 16 years ago
Resolution: --- → FIXED
Blocks: 294484
In the 05/17 Thunderbird build on Windows, I'm getting the following JS Message
on startup:

Install Location returned an item path that does not exist! Item Path:
Location Key: app-global Item ID: {972ce4c6-7e08-4474-a285-3208198ce6fd}

Could it be related to this change? I wonder if Thunderbird is missig a preference.
RE the registry location. Great idea :)

How would this differentiate between installing an extension in different
profiles? Users may want (say) adblock in their main profile but not in their
cut-down profile.
mscott: It might be related.  I filed bug 294576.  Not sure when I'll have time
to investigate it, but I'll try to make it a priority.

david: users can still disable global extensions in a given profile.  this
allows them to pick and choose what they want from the global set.
Flags: blocking1.8b2?
Keywords: fixed1.8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.