293548 - Provide windows registry install location for extensions

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Darin Fisher]

Provide windows registry install location for extensions.

See proposal here:
http://wiki.mozilla.org/Extension_Manager:Win32_Registry_Location

Comment 1

[Lech Deregowski [:lech]]

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?

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

Comment 2

[Darin Fisher]

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.

Comment 3

[Lech Deregowski [:lech]]

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.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

plugins already have a way to be found via the registry. so it sounds to me like
this bug really is about extensions.

Comment 5

[Darin Fisher]

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

Comment 6

[Darin Fisher]

Attachment: v1 patch

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.

Comment 7

[Darin Fisher]

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

Comment 8

[Darin Fisher]

> * 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/

Comment 9

[Darin Grimm]

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.

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Benjamin Smedberg]

Attachment: v1 patch with the registry bits removed

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.

Comment 12

[Darin Fisher]

benjamin, chofmann gave a= for the winreg API.  can we instead go for the full
patch here then?

Comment 13

[Darin Fisher]

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

Comment 14

[Benjamin Smedberg]

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

Comment 15

[Darin Fisher]

OK, probably best to add back the #ifdef XP_WIN parts to the patch you created.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 183737 [details] [diff] [review]
v1 patch with the registry bits removed

sr+a=[e-mail]

Comment 17

[Darin Fisher]

fixed-on-trunk

Comment 18

[Scott MacGregor]

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:
C:\build\trees\tbirddbg\mozilla\dist\bin\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd},
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.

Comment 19

[David McKenzie]

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.

Comment 20

[Darin Fisher]

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.