By making the updated system add-on install location return an empty set when
in safe mode it causes us to rescan and enable the default system add-ons.
The complication is calling the uninstall method on the updated add-ons when
switching to safe mode, for that we have to cache the fact that an add-on
can run in safe mode in the bootstrappedAddons data so it persists to the
next restart and can be accessed when the updated add-on has been hidden.
--HG--
extra : commitid : 2BJfLTeXSwu
extra : rebase_source : 79d6df358d6cec2d5e4b8df265a56da049d6fd58
Unifies the methods we have to check that bootstrap add-ons are correctly loaded
and makes it easier to make changes to them all in the future without needing to
re-sign add-ons etc.
This code allows a bootstrap script to use a shared script in a single line of
code. The shared scripts sends out all the relevant info over the observer
service, the add-ons manager test harness receives and retains the current state
for every add-on also performing sanity checks like making sure an "install"
method is always called before any "startup" method etc. It also provides simple
functions to check the state of a given add-on.
--HG--
extra : commitid : 3a3arh4wfjK
extra : source : 3d3f055ade5269d45ae3acc45c91da8390c25554
extra : amend_source : 5c47df309fda0c67d04877101ef0295ff66f651e
Unifies the methods we have to check that bootstrap add-ons are correctly loaded
and makes it easier to make changes to them all in the future without needing to
re-sign add-ons etc.
This code allows a bootstrap script to use a shared script in a single line of
code. The shared scripts sends out all the relevant info over the observer
service, the add-ons manager test harness receives and retains the current state
for every add-on also performing sanity checks like making sure an "install"
method is always called before any "startup" method etc. It also provides simple
functions to check the state of a given add-on.
--HG--
extra : commitid : 2mhI13iGMy6
extra : rebase_source : 1565c2909517c363a81b0516748c1c80a8890bdd
extra : amend_source : f8a1c8ad54d76109efbcad2ba5611cb89ab8e9a0
When we have a local copy of an add-on in the updated add-on set try to make a
temporary copy rather than re-downloading.
--HG--
extra : commitid : AzCd92Kt5u3
extra : rebase_source : 4a73c0129a0aa6b963c5a8de6bff8ebd9286e395
Checks the set that balrog gives us against the existing sets and switches
without needing to download again.
--HG--
extra : commitid : 1M0QvCVnfn6
extra : rebase_source : 5ce2c3f744128f3e9089fee036d8b63346cf8d72
This moves the app-shipped system add-ons into <appdir>/features. I've created
a new directory provider location for this since it allows us to override the
location without allowing external apps to do so as would be the case with
prefs.
--HG--
extra : commitid : 9lzIzbjvCpK
extra : rebase_source : 1f1f319eac2142ffbe6714289e6fb4e40cfd6088
We've wanted a hidden property for add-ons for a while so we can do things like
hide "uninstalled" sideloaded add-ons so this adds the basic version of it to
hide system add-ons.
--HG--
extra : commitid : 7il8eoXSVnu
extra : rebase_source : fec52514f15c1e74532012c0465bd5902eb179a9
The system add-on update checks will use the same update.xml format as GMP so
this splits out the code for parsing and downloading files into a standalone
module that both can reuse.
--HG--
extra : commitid : I89HsxRnP9T
extra : rebase_source : 1b38a03e202f73ba214604e083745e8c6b5984b5
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : KsbH21csjH4
extra : rebase_source : bc7c08de1ec6e802261b8cd294d88ee2c4e75c2d
The system add-on update checks will use the same update.xml format as GMP so
this splits out the code for parsing and downloading files into a standalone
module that both can reuse.
--HG--
extra : commitid : 31m1WDO3PCP
extra : rebase_source : f018d36b94460942b217e9a6bb4ec146309f9a55
extra : histedit_source : 15e2e92984ee8747b59d0278dab12f6872a17223
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : FuPUB9X4oYJ
extra : rebase_source : cfcd31d7da5f5b636a2ec11546dbada973d681de
extra : histedit_source : 3df840dc502c6ee4177f1858920d1260e4dc27af
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
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.
--HG--
extra : commitid : 8v5gChgFbgw
extra : rebase_source : 277807f800c98336c624718dc09b8ed44a25f201
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.
--HG--
extra : transplant_source : %9C%C1%AC%13%82%F2%94%18%9F%BC%CD%0C%FC%F65B%0DY%86%3F
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.
--HG--
extra : commitid : LYCHZGSoGwj
extra : rebase_source : c9bc96b36d23ba9b4374adead9b59059ccb02f39
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.
--HG--
extra : commitid : 4JAbEmPbxAc
extra : rebase_source : 136e4143a24f09dc88f4db1b5dc450568e40799a
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.
--HG--
extra : commitid : 81LpRFeugL5
extra : rebase_source : 8b532ee58e57194889fffd8d9558718e1b551bac
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.
--HG--
extra : commitid : CRFjjhiI4Pi
extra : rebase_source : 85091024e331dce72b9d704ca7a962a30d4b8407
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.
--HG--
rename : browser/components/extensions/bootstrap.js => toolkit/mozapps/extensions/internal/WebExtensionBootstrap.js
extra : commitid : 6Wzwp09S1AO
extra : rebase_source : 4592c790250a6ef5af6979800edf0b609ef0c027
