Disable dom.xhr.standard_content_type_normalization for now due to webcompat issues
Differential Revision: https://phabricator.services.mozilla.com/D8789
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
In reimplementing the OCSP fetching code in bug 1456489, we improperly
translated an assertion that relied on the nullness of a pointer to rely on the
length of a data structure that was populated by reference. It turns out that
this made the assertion invalid because we could return a successful result and
have filled the data structure with zero-length data and it still would be valid
to operate on (the decoding code returns a malformed input result in this case).
To fix this, we can simply remove the assertion. This patch also adds a test to
exercise this case.
Differential Revision: https://phabricator.services.mozilla.com/D8883
--HG--
extra : moz-landing-system : lando
Ensure the webcompat report addon is disabled upon load, if extensions.webcompat-reporter.enabled=false, take two
Differential Revision: https://phabricator.services.mozilla.com/D8678
--HG--
extra : moz-landing-system : lando
Bug 1495569 - Part 0: web-platform-test that verifies handling of offer without mid.
Bug 1495569 - Part 1: Ensure that answers are created with the transceiver's mid when the offer did not have a mid.
Differential Revision: https://phabricator.services.mozilla.com/D8853
--HG--
extra : moz-landing-system : lando
Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Differential Revision: https://phabricator.services.mozilla.com/D8878
--HG--
extra : moz-landing-system : lando
Delaying the loading of some OS.Constants.Path members to reduce startup
IO is breaking the test_system_delay_update.js test, because it leaves
tmpaddon-* files in the user's temp directory. As far as I can tell this
is okay (please correct me if wrong) - but the error in AddonTestUtils
was being avoided because the OS.Constants.Path.tmpDir value was being
read before we override TmpD for the test. So now we are leaving them
to be ignored in the TmpD directory we specified, rather than leaving
them to be ignored in the user's temp directory.
Depends on D6080
Differential Revision: https://phabricator.services.mozilla.com/D6081
--HG--
extra : moz-landing-system : lando
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
These calls to GetPathToSpecialDir are performing some unnecessary IO
during early startup which we'd like to defer. Simply adding the
required ones to the list in osfile_async_front.jsm should mostly get
us there.
Differential Revision: https://phabricator.services.mozilla.com/D6079
--HG--
extra : moz-landing-system : lando
This adds `mach try release` which adds temporary changes to enable staging
release to run.
Differential Revision: https://phabricator.services.mozilla.com/D8625
--HG--
extra : moz-landing-system : lando
These were originally enabled becuase the opt builds on mozilla-beta and
mozilla-release had the update channel set. Since Bug 1498028, only the nightly
(i.e. shippable) builds have the update channel set, the build system no longer
honors the request to enable stubs. This was causing failures in downstream tasks
that expected stub installers to be built.
Differential Revision: https://phabricator.services.mozilla.com/D9005
--HG--
extra : moz-landing-system : lando
When defaulting to a null triggering principal, these tests would fail
when loaded remotely. This patch adds explicit system triggering
principal to the loadURI calls.
Differential Revision: https://phabricator.services.mozilla.com/D8461
--HG--
extra : moz-landing-system : lando
nsIWebNavigation.loadURI actually has an optional triggering principal
parameter that RemoteWebNavigation hasn't implemented. This patch adds
the extra parameter to RemoteWebNavigation's implementation so
triggering principals are passed properly when loadURI is called with
a triggering principal.
Differential Revision: https://phabricator.services.mozilla.com/D8460
--HG--
extra : moz-landing-system : lando
The use of <iframe mozbrowser> in test_saveHeapSnapshot_e10s_01.html has
implicitly depended on the "network.disable.ipc.security" pref set to
false, which is the default for desktop and not applicable for Fennec.
With the new mobile test harness, this pref needs to be set explicitly
by the test.
Differential Revision: https://phabricator.services.mozilla.com/D7786
--HG--
extra : moz-landing-system : lando
