Because plugin state in the content now contains blocklist state, and is updated
when the blocklist updates, we don't need to ask the parent if we're checking
blocklist state. All the consumers should now be asking the plugin code directly,
so we can stub out the last API here. We should look at removing the content side
of this service entirely, but that's something for a follow-up bug.
MozReview-Commit-ID: DE8s8RwT42r
--HG--
extra : rebase_source : 06fbc304e99679f55c7cdc52404cd138221feca3
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
Addon's "Preferences" tab was opening up to the right of ALL tabs rather than next
to the current tab. This behavior has been corrected, and the aforementioned
tab is now placed relative to the opening tab.
MozReview-Commit-ID: APiUR9VkEEt
--HG--
extra : rebase_source : 3b274b9663ae9084c5d3b1823cc044b6adf629b3
When we run tests in parallel (and probably occasionally when we don't), we
sometimes wind up getting a DOMContentLoaded event for about:blank before we
actually start loading the background page, which causes tests which rely on
the background page being loaded to fail.
This also fixes some noisy warnings from XPIProvider which make actual issues
more difficult to diagnose.
MozReview-Commit-ID: 4CiccISJ7Pt
--HG--
extra : rebase_source : 25356f5162b19cd28a6f8d004e04a85038ecff28
Several of our existing plain mochitests use the message matching features of
SimpleTest.monitorConsole. Having a similar utility for xpcshell tests would
make it much easier to migrate these tests to xpcshell.
MozReview-Commit-ID: 38pPanhN5Iu
--HG--
extra : rebase_source : 54a71d9ed01fdd32747742b8aace414d4fb96398
This retains support for installing unpacked dictionaries, since Hunspell only
supports loading dictionaries from ordinary filesystem paths.
Unpacked extensions are no longer supported on production, except during
development. WebExtensions have no support for the unpacked flag at all, and
specially signed legacy extensions are forbidden from using it, so there's no
point in maintaining support for this install code. Or, more importantly, for
running a nearly complete duplicated set of tests in order to exercise it.
MozReview-Commit-ID: 1fKVgSelJQ8
--HG--
extra : rebase_source : a2e9086a3d050b66eab9c17fff9c2f7189911832
extra : amend_source : da8f6425ec74a824a3d19f13bb4eb51980cd64c1
As described in the bug, this is intended as a temporary solution to
enable some experiments. If this becomes a real feature, UX will
put some thought into a better startup experience.
MozReview-Commit-ID: 4DGMHj29M3e
--HG--
extra : rebase_source : a108fd58d4703c3110790f99e4936e6fee323cd2
AddonTestUtils.overrideBuiltIns sets |security.turn_off_all_security_so_that_viruses_can_take_over_this_computer| to true when it starts. It then naively sets it to false, assuming that that was the original value. This patch simply corrects that behavior to return the value to the previously set value, whatever that may have been.
MozReview-Commit-ID: KbhmoixBvpW
--HG--
extra : rebase_source : 0440ca6f4867e71fe1c3b10eb9a4fb735add4c29
This patch additionally removes the check where if AddonManagerPrivate.backgroundUpdateTimerHandler does not call AddonManagerInternal.backgroundUpdateCheck if updates to all addons are disabled. The check is redundant as AddonManagerInternal.backgroundUpdateCheck makes those same checks.
MozReview-Commit-ID: FxS8127JYkn
--HG--
extra : rebase_source : 5268750a9f88064e2892e0294704470697e81e80
Back out bug 1417254, bug 1348087, and bug 1416295 for continuing to cause app update failures.
Backed out changeset ec6f1b3c1317 (bug 1417254)
Backed out changeset df5703f27971 (bug 1416295)
Backed out changeset ae2fcdddead1 (bug 1348087)
Backed out changeset fb54cd45fa10 (bug 1348087)
Backed out changeset edfa340ec9fb (bug 1348087)
Switch from the old XML-based AMO metadata API to the modern JSON based
API. This turned into something between a modest update and complete
rewrite. Most notably, external APIs became (mostly) promise-based. The
exception is getCachedAddonById() which XPIInstall.jsm requires a
synchronous callback from.
Also, hopefully we will be able to get rid of a bunch of this metadata
handling soon. If this code had a long life ahead of it, the unit tests
could use some more attention, but I mostly did the minimum here just to
keep them running for now with the expectation that we'll be able to get
rid of them within some small number of months.
MozReview-Commit-ID: 3DRaBdWGaiJ
--HG--
rename : services/sync/tests/unit/addon1-search.xml => services/sync/tests/unit/addon1-search.json
rename : services/sync/tests/unit/bootstrap1-search.xml => services/sync/tests/unit/bootstrap1-search.json
rename : services/sync/tests/unit/missing-sourceuri.xml => services/sync/tests/unit/missing-sourceuri.json
rename : services/sync/tests/unit/missing-xpi-search.xml => services/sync/tests/unit/missing-xpi-search.json
rename : services/sync/tests/unit/rewrite-search.xml => services/sync/tests/unit/rewrite-search.json
rename : services/sync/tests/unit/systemaddon-search.xml => services/sync/tests/unit/systemaddon-search.json
extra : rebase_source : f25d78b938768041c5c05b72a1f7ff3a7dee8275
Compatibility override data was previously stored in an object attached
to each AddonInternal instance and awkwardly copied around in various
places. In the new AMO API, compatibility overrides come from a different
API endpoint -- lay the groundwork for maintaining that data separately
inside AddonRepository by creating a new internal API for fetching
compatibility override data. Note there is some code related to staged
installs of non-restartless addons that refers to the old
compatabilityOverrides property, that code should ideally get removed
soon but for now it is unreachable.
MozReview-Commit-ID: EUZhPsTc2q
--HG--
extra : rebase_source : 23268c991e68a087e0882783156fb668301a52ef
Remove unused imports of AddonRepository.jsm plus some more
leftover bits from in-browser search results.
MozReview-Commit-ID: AZyAtnHvaMP
--HG--
extra : rebase_source : 6085ed3a22bd9a43f8882f604b97aa55b8b788c5
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b