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.
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.
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.
Simple obvious fix. Adds tests by making BootstrapMonitor (which
test_experiments.js and others use for verifying bootstrap startup and shutdown)
verify the list of registered chrome manifests at various points. Without the
fix this makes test_experiment fail as expected.
The Android-specific AddonUpdateService has a bit of redundant code
because AddonManagerPrivate has a backgroundUpdateCheck method that does
a lot of the same thing. This patch makes AddonUpdateService call that
method so there's less code and more consistency.
This requires flipping the "extensions.update.enabled" pref, which was
disabled in bug 528588 for showing the XUL addon update dialog. I don't
think this is relevant anymore in native Fennec and with the later
rewrite of AddonManager, so I'm fairly certain it's okay to flip that
pref.
The patch also disables the AddonManager update timer because we have
our own update timer on Android.
Experiments should differ from normal add-ons in a few ways:
* They can always be enabled regardless of compatibility info
* They default to disabled when installed
* They cannot be checked for updates
* They only stay enabled for the lifetime of the current process
* The UI doesn't give users the ability to enable/disable
This makes a few changes to keep these differences but remove much of the special casing code for experiments.
Being able to use regardless of compatibility was mostly fixed by bug 1220198 but I've also removed the redundant override in isCompatible.
Previously the "enabled until restart" feature worked with by not updating the DBAddonInternal object and instead using a hack to make the wrapper still seem enabled. This seems likely to break other code that relies on the state of the DBAddonInternal object so instead we update that as normal and simply don't persist the enabled state to disk.
Also switch the DBAddonInteral.prototype code to use some newer JS features.
I've removed the hack from addon.permissions which was hiding the enable/disable buttons in the UI and instead just hidden them in the UI stylesheet. This makes the API make sense and means callers can use addon.permissions to verify that enabling will work.
In order to meet the addon signing requirement for tests, specialpowers
needs to be installed at gecko runtime. This means it must be restartless.
This patch packages specialpowers as a restartless addon, but it does not
yet install it at runtime.
Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.
This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.
I tried to keep the changes to existing tests as minimal as
possible. There were a few exceptions, though:
* test_update_ignorecompat.js was completely broken. I couldn't
figure out why it was suddenly failing after I changed it to use
`add_test`, and it turned out that it had been failing all along,
but in a way that the harness didn't pick up.
* I changed most of the `do_throw` in update callbacks to `ok(false`
because it took me about an hour to figure out where the test was
failing when I hit one of them.
* I made some changes to sync `test_update.js` and `test_update_ignorecompat.js`
where one appeared to have been changed without updating the
other.
* I made `promiseFindAddonUpdates` a bit more generic, because I was
planning to convert most of `test_update.js` to use it, rather
than nested callbacks. I changed my mind a quarter of the way
through, but decided to keep the changes, since they'll probably
be useful elsewhere.
I tried to keep the changes to existing tests as minimal as
possible. There were a few exceptions, though:
* test_update_ignorecompat.js was completely broken. I couldn't
figure out why it was suddenly failing after I changed it to use
`add_test`, and it turned out that it had been failing all along,
but in a way that the harness didn't pick up.
* I changed most of the `do_throw` in update callbacks to `ok(false`
because it took me about an hour to figure out where the test was
failing when I hit one of them.
* I made some changes to sync `test_update.js` and `test_update_ignorecompat.js`
where one appeared to have been changed without updating the
other.
* I made `promiseFindAddonUpdates` a bit more generic, because I was
planning to convert most of `test_update.js` to use it, rather
than nested callbacks. I changed my mind a quarter of the way
through, but decided to keep the changes, since they'll probably
be useful elsewhere.
If not building the Windows Maintenance Service, avoid a dependency
on crypt32.dll and wintrust.dll.
Also, avoid setting sUsingService inside the updater code; this
ensures that all Maintenance Service related codepaths are skipped.
Rather that trying to get the method from the sandbox global object which will
only work for var and function declared methods instead evaluate the function
name in the sandbox scope and get the result which will give us access to the
lexical scope.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
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.
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.
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.
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.
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.
This performs the update check for system add-ons. It runs as part of the daily
add-on update checks similar to hotfix checks. Currently no URL is set so builds
won't actually start checking yet.
I've taken a few shortcuts here by only staging updates and needing a restart to
install as well as always downloading updates rather than using existing local
copies. At least the latter probably needs fixing before turning this on but
it makes more sense to iterate on those in tree.
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.
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.
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
This performs the update check for system add-ons. It runs as part of the daily
add-on update checks similar to hotfix checks. Currently no URL is set so builds
won't actually start checking yet.
I've taken a few shortcuts here by only staging updates and needing a restart to
install as well as always downloading updates rather than using existing local
copies. At least the latter probably needs fixing before turning this on but
it makes more sense to iterate on those in tree.
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.
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.
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.
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.
