This adds a bunch of structure supporting a promise-based API on the
AddonManager object that is exposed to webpages and adds the first example,
getAddonByID.
MozReview-Commit-ID: CCEFl4R1o81
--HG--
extra : rebase_source : 6206982c687a8e1733ef323488fc2710a4967688
Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: CRpZy873GP6
--HG--
extra : rebase_source : d355e5f0f13211cbd81e2a91cfe6191f5e84adb2
extra : histedit_source : eb85af7438b493a22fd9a4c32ab254e6a01b7cb3
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 5c19b92e4242088b6fc7a268f255fe9a795928f6
extra : source : 3e5b6df276a9a20fe7b3655656e62a09bc46aaa9
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 9d33fb313aec69e98ac3027d20a6bfc247f27f63
Moved these mostly onto the prototype. We couldn't do this before without making
the target of the wrapper a property of the wrappers and we don't want to expose
that but now WeakMaps allow us to get the target without exposing it.
Once change with this approach is that when the test suite shuts down the
add-ons manager it kills the map and so wrappers cease to function. A couple of
tests were relying on accessing wrapper properties after that but that would
have likely been unsafe anyway.
--HG--
extra : commitid : 6OI6dLyM45D
extra : rebase_source : c8a53360ce582186dcdc5cbf0dfc2b5057881eac
Both for brevity and to remove the use of |self = this|.
--HG--
extra : commitid : 7gNXRCzxPxM
extra : rebase_source : 4dccdf8bf99f5979664ca3ca3d9e61f66e217bfe
We used to need explicit names for functions to make stack traces display
properly. The JS engine is smarter now so doesn't need them and they just
make the code messy and redundant.
--HG--
extra : commitid : 4FEIiQYhRQu
extra : rebase_source : 26689d5417f592d0f327f32076245cb4f154229a
For build speed, for correct line numbers in errors, for faster development, for so many reasons.
Still a couple of cases left mostly in XUL files for different strings on Windows.
Bonus: The new lexical scope means ADDON_SIGNING and REQUIRE_SIGNING can just
be declared as regular constants and outside code can't get to them easily.
--HG--
extra : commitid : Kj8khjuCwG2
extra : rebase_source : 2e0a3143900c0c414cda43254306f0c070f8e621
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
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
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 : FAyc1y0WszT
extra : rebase_source : 308a674ec0e3f81ee3e0533b7014c37477860d67
