When a lightweight theme is active the default theme is the selected skin but
the default theme's addon object is marked as inactive (to deal with the horror
of only allowing the user to select a single theme through the UI).
During startup we should only switch back to the default theme if there is a
non-default skin selected that we didn't see.
Makes sure that add-on objects always have the _installLocation property for
the location they will be installed into so that isUsableAddon can test for the
right signature.
This adds two new directory install locations. One contains the default system
add-ons that ship with the application, the other contains system add-on that
will eventually be updatable at runtime.
The updatable location tracks the expected list of add-ons in a pref. and only
returns add-ons from that list when asked for its list of add-ons.
After processFileChanges has scanned all add-ons and updated the database it
checks if the updated system add-ons match the expected set. If not we ignore
those add-ons when working out which add-ons should be visible. If they do match
then we ignore the app-shipped system add-ons when working out which are
visible.
Most directory install locations are immutable at runtime. Only the profile
location can be installed into and uninstalled from. The system add-on locations
will be immutable as well but also be extended with some extra functionality so
it is useful to split the immutable parts out into a shared class that both
the mutable location and eventually system add-on locations can inherit from.
Normal directory install locations expect add-ons to exist on disk with the
naming convention "<id>.xpi". Originally system add-ons were going to do
something different so I started working on this. In the end it is unnecessary
but this work did reveal some cases where _sourceBundle wasn't being updated
for add-ons and removing most of these assumptions is still valuable.
The add-ons manager recognises the notion of "install locations". Each location
can contain add-ons that are installed in the application. There are two main
types, directory locations which exist as a directory somewhere in the
filesystem and registry locations which exist in the Windows registry. The
profile location is the one where add-ons installed through the UI exist, the
other locations are for add-ons that are bundled with the application,
installed by the OS or by third-party applications.
Install locations have priorities. The profile location has the highest priority
then the others gradually lower priorities. When an add-on exists in more than
one install location the version in the highest priority location is the one
that is visible and can be active in the application. We still retain details
about the other versions in the database.
On every startup the add-ons manager scans over these install locations to see
if the set of installed add-ons has changed at all. A very quick check is done
to see if the more thorough check in processFileChanges (which synchronously
loads the add-ons database and install manifests for the add-ons) is needed.
The job of processFileChanges is to load information about all the add-ons and
update the add-ons database to match. It has to decide which add-ons to make
visible, track what changes were made to the visible set of add-ons and call
restartless add-ons install and uninstall scripts.
The original version of processFileChanges attempted to optimise this by doing
all of the work in a single loop over the add-ons in the locations. This mostly
worked but made certain situations difficult to handle (see bug 607818 f.e.).
There isn't much need for this level of optimisation. We're already in a slow
pass and once all the data is loaded off the disk looping over it is fast.
This changeset moves processFileChanges into the XPIProviderUtils file which is
lazy loaded when necessary. While most of the code is the same it instead does
one loop to update the database and gather information, then a second loop to
update add-on visibility, record changes and call bootstrap scripts.
This adds two new directory install locations. One contains the default system
add-ons that ship with the application, the other contains system add-on that
will eventually be updatable at runtime.
The updatable location tracks the expected list of add-ons in a pref. and only
returns add-ons from that list when asked for its list of add-ons.
After processFileChanges has scanned all add-ons and updated the database it
checks if the updated system add-ons match the expected set. If not we ignore
those add-ons when working out which add-ons should be visible. If they do match
then we ignore the app-shipped system add-ons when working out which are
visible.
Most directory install locations are immutable at runtime. Only the profile
location can be installed into and uninstalled from. The system add-on locations
will be immutable as well but also be extended with some extra functionality so
it is useful to split the immutable parts out into a shared class that both
the mutable location and eventually system add-on locations can inherit from.
Normal directory install locations expect add-ons to exist on disk with the
naming convention "<id>.xpi". Originally system add-ons were going to do
something different so I started working on this. In the end it is unnecessary
but this work did reveal some cases where _sourceBundle wasn't being updated
for add-ons and removing most of these assumptions is still valuable.
The add-ons manager recognises the notion of "install locations". Each location
can contain add-ons that are installed in the application. There are two main
types, directory locations which exist as a directory somewhere in the
filesystem and registry locations which exist in the Windows registry. The
profile location is the one where add-ons installed through the UI exist, the
other locations are for add-ons that are bundled with the application,
installed by the OS or by third-party applications.
Install locations have priorities. The profile location has the highest priority
then the others gradually lower priorities. When an add-on exists in more than
one install location the version in the highest priority location is the one
that is visible and can be active in the application. We still retain details
about the other versions in the database.
On every startup the add-ons manager scans over these install locations to see
if the set of installed add-ons has changed at all. A very quick check is done
to see if the more thorough check in processFileChanges (which synchronously
loads the add-ons database and install manifests for the add-ons) is needed.
The job of processFileChanges is to load information about all the add-ons and
update the add-ons database to match. It has to decide which add-ons to make
visible, track what changes were made to the visible set of add-ons and call
restartless add-ons install and uninstall scripts.
The original version of processFileChanges attempted to optimise this by doing
all of the work in a single loop over the add-ons in the locations. This mostly
worked but made certain situations difficult to handle (see bug 607818 f.e.).
There isn't much need for this level of optimisation. We're already in a slow
pass and once all the data is loaded off the disk looping over it is fast.
This changeset moves processFileChanges into the XPIProviderUtils file which is
lazy loaded when necessary. While most of the code is the same it instead does
one loop to update the database and gather information, then a second loop to
update add-on visibility, record changes and call bootstrap scripts.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
Also corrects a race condition where if an extension was disabled before it
had finished loading its manifest it would have called GlobalManager.init but
never call GlobalManager.uninit.
