This allows native messaging binaries to identify the add-on that
invoked the native messaging app, in case more than one add-on is
allowed to launch the native messaging app.
MozReview-Commit-ID: GgjwfJDbBkW
--HG--
extra : rebase_source : b60d33e9f3936f26b8792ef5cd1f9fea304f29ae
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : 100092c2f2ff609362a724fff60f46dd6e49c94e
extra : intermediate-source : d10f5ccd882b965fcad39914f7c3c930d1301a41
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
This allows us to write files coming from a finder or other source
that isn't directly the filesystem.
MozReview-Commit-ID: KhPSD0JYzsQ
--HG--
extra : rebase_source : fea376f642e20e8c7723506fd4a73e3f8ac5d0e5
extra : intermediate-source : a872303fd08497bbde0e3b4cea09a88a4182810e
extra : source : ae8bce278626bc84914063f93292ac5e825eec36
Most consumers of `GetBookmarkIdsForURI` already don't need tags, the only
consumer which does (`TaggingService`) has been changed to use a separate
database query.
MozReview-Commit-ID: LabjaA6Q0GF
--HG--
extra : rebase_source : e13dc730a53b5b46ca1766bf896112aa65aa00af
setTestName was used for logging which test was being run for the
JS Tests used in B2G.
MozReview-Commit-ID: FNF4Sm7vAYM
--HG--
extra : rebase_source : b12fd8ce04e7da739a8a5ec0e7b30b6734c58e4a
This is a remanent of the B2G code for injecting Mochitest style tests
into Gecko. This is no longer used by anything and is now dead code.
MozReview-Commit-ID: 4qaB3vxQzon
--HG--
extra : rebase_source : 3af2c7655ecd2d03f266d0a1ad02eadfea1b1a0b
The change to l10n packager from bug 780562 worked in practice because
no chrome category had exclusively manifest entries with flags, which
we're changing in this bug.
It turns out this was only due to a missing change in the patch for bug
780562.
--HG--
extra : rebase_source : 3c8c31c37d8fb48bb99b1758bcd8ef5f32c71fe0
In case some legacy third-party things were relying on those files being
under a unix/ directory, revert the part of changeset c94e87a18096 that
renamed global-platform/unix to global-platform/gtk.
--HG--
extra : rebase_source : bb78b309fe59ee5f76f276e54539e157eb019e69
Since it wasn't possible to have specific manifest entries for !Darwin
!WINNT !Android, a few places in the tree use the following pattern:
entry-for-unix
entry-for-osx os=Darwin
entry-for-windows os=WINNT
This works because subsequent manifest entries with more specific flags
override previous manifest entries.
Incidentally, this led to problems such as the one mentioned in
changeset c94e87a18096.
Now that there is a flag for !Darwin !WINNT !Android, we can use it
instead.
--HG--
extra : rebase_source : 6f20a9b31d48c8ee4126662730e95789de740971
Manifest entries can contain flags, one of which allows to match on the
os running Gecko. The match is performed against the value returned by
nsIXULRuntime.getOS, which itself comes from the build-system's
OS_TARGET.
In practice, this means that things like os=WINNT, os=Darwin,
os=Android, os=Linux are valid filters, but the latter is too specific,
and most of the time, one would want something that is "any OS but
WINNT, Darwin, Android", which can't be expressed with manifest entry
flags (there is no "and" for them, only "or").
For convenience, we add the keyword "LikeUnix", which has that meaning.
--HG--
extra : rebase_source : ce2549fab96cb1df3f984e43cb08413cad49479e
Remove now useless self reference in OpenDatabaseOp::SendResults(). Add comments for how to call
FactoryOp::Run() safely and also add comments to all the call sites. This prevents a self destruction
while Run() (or a method that is called by Run()) is still being executed. Also fix
TransactionDatabaseOperationBase which also calls Run() directly in NoteContinueReceived().
--HG--
extra : rebase_source : dcc5f6e7e2974e8e0730687dd0dedac9d3e60060
setTestName was used for logging which test was being run for the
JS Tests used in B2G.
MozReview-Commit-ID: FNF4Sm7vAYM
--HG--
extra : rebase_source : 6ad739d2ff9bf3d6bafaed0450c8794a257657e7
This means they will be copied to $PROFILE/extensions, which the sandbox allows
access to; if they are installed as temporary addons, loading frame scripts in
the content process tries to read from wherever they happen to be on disk. This
breaks running tests with a packaged build once we have full read-restrictions
for the content process sandbox.
MozReview-Commit-ID: 7ZiiM9FMXfG
--HG--
extra : rebase_source : d2cf3a2d06df9099dc6056fae351200eaa1d0ca9
Without this change, browser_update.js "resets" a preference that it never
changed to a different value, which leaks through to future tests. This was
introduced in a8fcca075fde, and appears to be a simple mistake since that change
removes a setup/teardown pref change pair, but the prefs it changes are two
different ones!
This leaked pref change leads to test failures when special powers and mochitest
are installed as non-temporary addons.
MozReview-Commit-ID: 2jx3fB1iZMx
--HG--
extra : rebase_source : 35394dda16814d80116854bd40c00c95f30d34e2
The current DOM tests for about:debugging implicitly assume that there is a
temporary addon installed before they start. This is currently always true
because mochitest and specialpowers are installed as temporary addons, but the
goal of this bug is to install them as non-temporary addons.
The specific cause of the breakage is the assumption that uninstalling an addon
removes an <li> from the addons <ul>, but when you go from one addon to zero the
entire <ul> is removed.
MozReview-Commit-ID: VJIcy17uQc
--HG--
extra : rebase_source : a398f20e9befb7e8ff307368557ae7b9c0c75fba
This is a remanent of the B2G code for injecting Mochitest style tests
into Gecko. This is no longer used by anything and is now dead code.
MozReview-Commit-ID: 4qaB3vxQzon
--HG--
extra : rebase_source : b4b7e66452b7ce7335ef5f509957121f403d7043
This patch effectively removes indexing from the on-push style l10n tasks. These tasks are currently only used on try.
We don't want the indexing because the index's themselves conflict with the indexes used on Nightly l10n tasks, for now, and would get added here in any full graph if the locale list is small enough. We can revisit this decision whenever on-change L10n for non-try is a thing, and/or when we have explicit nightly routes for l10n
MozReview-Commit-ID: DRydwUEtPTp
--HG--
extra : rebase_source : 816ba623ba730aa672803bbf6a25450265d7aaf6
If we set a transform in push_stacking_context, it changes the internal
WebRender behaviour to make that stacking context a reference frame, and
things inside it are positioned differently. This is true even if the
transform is an identity transform.
In most cases we are hitting this and sending an identity transform
through, when in fact we want to be sending a None value to WebRender so
that it doesn't create reference frames. This is a partial fix, a proper
fix will be done in bug 1345577 by separating the CSS transform from the
other transforms that FrameLayerBuilder invents.
MozReview-Commit-ID: ElSs3hFMD2D
