Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
Some fields of /etc/os-release are optional, so do not throw KeyError's when they're missing.
Differential Revision: https://phabricator.services.mozilla.com/D48984
--HG--
extra : moz-landing-system : lando
This reverts Bug 1355584 which made it optional for MinGW. We now use
it in MinGW so let's make it required again.
Differential Revision: https://phabricator.services.mozilla.com/D48883
--HG--
extra : moz-landing-system : lando
2019-10-11 Kai Engert <kaie@kuix.de>
* automation/release/nspr-version.txt:
Bug 1583068 - Require NSPR version 4.23 r=jcj
[93245f5733b3] [NSS_3_47_BETA1]
2019-10-11 Kevin Jacobs <kjacobs@mozilla.com>
* coreconf/config.gypi, lib/freebl/freebl.gyp:
Bug 1152625 - Add gyp flag for disabling ARM HW AES r=jcj
Adds an option to disable ARMv8 HW AES, if `-Ddisable_arm_hw_aes=1`
is passed to build.sh.
Depends on D34473
[9abcea09fdd4]
2019-10-11 Makoto Kato <m_kato@ga2.so-net.ne.jp>
* lib/freebl/aes-armv8.c:
Bug 1152625 - Part 2. Remove __builtin_assume to avoid crash on PGO.
r=kjacobs,mt
`AESContext->iv` doesn't align to 16 bytes on PGO build, so we
should remove __builtin_assume. Also, I guess that `expandedKey` has
same problem.
[1b0f5c5335ee]
* lib/freebl/Makefile, lib/freebl/aes-armv8.c, lib/freebl/aes-armv8.h,
lib/freebl/freebl.gyp, lib/freebl/intel-aes.h,
lib/freebl/rijndael.c:
Bug 1152625 - Support AES HW acceleration on ARMv8. r=kjacobs,jcj
[efb895a43899]
2019-09-06 Martin Thomson <mt@lowentropy.net>
* gtests/ssl_gtest/ssl_auth_unittest.cc,
gtests/ssl_gtest/ssl_ciphersuite_unittest.cc,
gtests/ssl_gtest/ssl_extension_unittest.cc,
gtests/ssl_gtest/ssl_fuzz_unittest.cc,
gtests/ssl_gtest/tls_esni_unittest.cc, lib/ssl/ssl3con.c,
lib/ssl/ssl3exthandle.c, lib/ssl/sslimpl.h, lib/ssl/tls13con.c:
Bug 1549225 - Up front Signature Scheme validation, r=ueno
Summary: This patch started as an attempt to ensure that a DSA
signature scheme would not be advertised if we weren't willing to
negotiate versions less than TLS 1.3. Then I realized that we didn't
do the same for PKCS#1 RSA.
Then I realized that we were still willing to try to establish
connections when we had a certificate that we couldn't use.
Then I realized that ssl3_config_match_init() wasn't being run
consistently. On resumption, we only ran it when we were PARANOID.
That's silly because we weren't checking policies.
Then I realized that we were allowing ECDSA certificates to be used
when the named group in the certificate was disabled. We weren't
enforcing that consistently either. However, I also discovered that
the check we have wouldn't work without a tweak because in TLS 1.3
the named group is part of the signature scheme; the configured
named groups are only used prior to TLS 1.3 when selecting
ECDSA/ECDH certificates.
So that sounds like a lot of changes but what it boils down to is
more robust checking of the configuration prior to starting a
connection. As a result, we should be offering fewer options that
we're unwilling or unable to follow through on. A good number of
tests needed tweaking as a result because we were relying on getting
past the checks in those tests. No real problems were found as a
result; this just moves failures that might arise from
misconfiguration a little earlier in the process.
[9b418f0a4912]
2019-10-08 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/pk11_gtest/pk11_der_private_key_import_unittest.cc,
lib/pk11wrap/pk11pk12.c:
Bug 1586947 - Store nickname during EC key import. r=jcj
This patch stores the nickname (if specified) during EC key import.
This was already done for all other key types.
[c319019aee75]
2019-10-08 Marcus Burghardt <mburghardt@mozilla.com>
* lib/certdb/stanpcertdb.c, lib/pk11wrap/pk11load.c,
lib/pki/pki3hack.c:
Bug 1586456 - Unnecessary conditional in pki3hack, pk11load and
stanpcertdb. r=jcj
Some conditionals that are always true were removed.
[b34061c3a377]
Differential Revision: https://phabricator.services.mozilla.com/D49030
--HG--
extra : moz-landing-system : lando
webdriver depends on the regex crate for unit testing which adds
significant overhead building the crate. We could depend on
serde_json::from_value() instead, following the same pattern set
forth in the marionette crate.
Differential Revision: https://phabricator.services.mozilla.com/D48318
--HG--
extra : moz-landing-system : lando
This patch factors out some of the initial test case in
fetch-waits-for-activate.https.html (which only tests "pending" fetch events
for a navigation request) to share with a new test case that tests
"pending" fetch events for a subresource request with a request body.
Both tests in the file have a high-level structure of:
1) Register a Service Worker and wait until its state is "activating" but don't
let its state reach "activated".
2) Fire a fetch event that will be controlled by that Service Worker, which
should wait until the Service Worker's state advances to "activated".
3) Wait for the fetch to see that the worker isn't "activated". This step isn't
directly observable by content, so the test's method to determine this can
have false posities (but should never cause the test to unexpectedly fail).
4) Tell the Service Worker to advance to "activated".
5) Verify the fetch that was dispatched while the Service Worker was
"activating" is successfully handled.
Differential Revision: https://phabricator.services.mozilla.com/D49031
--HG--
extra : moz-landing-system : lando
In ServiceWorkerPrivateImpl::SendFetchEvent, a heap-allocated AutoIPCStream can
point to a stack-allocated IPCStream (part of an IPCInternalRequest). If this
IPCStream is destroyed before the AutoIPCStream, the AutoIPCStream will have a
dangling pointer (and this is the case if SendFetchEvent is called when the
Service Worker's state is "activating" rather than "activated").
This patch moves around the logic to handle the AutoIPCStream's lifetime to
ensure it its lifetime is within its IPCStream's lifetime. The larger issue
might be that AutoIPCStream doesn't have inherent lifetime guarantees (it'll
definitely outlive its IPCStream if it points to its embedded one, but it
doesn't own any external IPCStreams it might point to).
Differential Revision: https://phabricator.services.mozilla.com/D48935
--HG--
extra : moz-landing-system : lando
Without this patch, the `CHECK_BLOCK_AND_LINE_DIR` soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.
Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.
Add reftests to verify that BFC bits are added to the child block if the
parent and child has the same block-direction, but different sideways
bit; also, add reftests to ensure that "text-orientation: sideways"
doesn't add BFC bits.
Differential Revision: https://phabricator.services.mozilla.com/D45912
--HG--
extra : moz-landing-system : lando
In 817406-4.html, `<body style="direction: rtl;">` needs to propagate up
to `<html>`, so we should compare its result to 817406-1-ref.html.
Differential Revision: https://phabricator.services.mozilla.com/D45482
--HG--
extra : moz-landing-system : lando
This also reduces the size of BlobItemData which will give us
some free performance on SVGs that have a lot of items by reducing
our working set size.
Differential Revision: https://phabricator.services.mozilla.com/D49023
--HG--
extra : moz-landing-system : lando
IsCurrentInnerWindow() should only return true when we are the current inner
of our BrowsingContext, which has a longer lifetime than individual
GlobalWindowOuter instances. In particular, if our BrowsingContext has no
GlobalWindowOuter hanging off it, that means that currently it's hosting an
inner window from some other process and we are not the current inner. If it
_does_ have a GlobalWindowOuter hanging off it, it's possible that this is not
the same as our mOuterWindow, if the BrowsingContext navigated to a different
site and then navigated back to our site.
Therefore, we need to check that we are the current inner of whatever the
BrowsingContext's current GlobalWindowOuter is, if it has one at all.
Differential Revision: https://phabricator.services.mozilla.com/D48595
--HG--
extra : moz-landing-system : lando
StringBuffer directly calls `NewInlineString` for short strings, which prevents
looking up static strings.
Differential Revision: https://phabricator.services.mozilla.com/D40074
--HG--
extra : moz-landing-system : lando
By flipping this pref, we can force ASRouter to load the local flient files for l10n. Note I will make another change for ASRouter to decide which fluent source to use.
Differential Revision: https://phabricator.services.mozilla.com/D49010
--HG--
extra : moz-landing-system : lando
It doesn't have any useful effect given the way Fission chooses processes, and
complicates the window.open logic in ways that are hard to maintain and cause
problems.
Differential Revision: https://phabricator.services.mozilla.com/D48749
--HG--
extra : moz-landing-system : lando
This patch creates a new API to the nsIProfiler interface, through the activeConfiguration
property. It exposes the internal configuration of the profiler. In addition, this information
is serialized into the profile meta object.
Differential Revision: https://phabricator.services.mozilla.com/D48733
--HG--
extra : moz-landing-system : lando
If the captive portal service is disabled then enabled again when in a captive
portal, we sometimes don't send the captive-portal-login observer notification
because we're reusing the same mCaptiveDetector object, which believes it's
already sent it.
We should use do_CreateInstance instead of do_GetService for this.
Differential Revision: https://phabricator.services.mozilla.com/D48819
--HG--
extra : moz-landing-system : lando
The new error message is still not great, but it's a lot better than having %s
as the description of what's going on.
Differential Revision: https://phabricator.services.mozilla.com/D47915
--HG--
extra : moz-landing-system : lando
When we have a parser-created iframe which starts out in-process, transitions
to remote, and then transitions back to in-process, we create separate
DocShells for the first and last in-process loads. Since both are
network-created, and have the same child index, they both try to add
themselves as children to their parent's SHistory at the same index. And since
the entry for the first DocShell already exists at that index when we try to
add the second, that triggers an assertion.
This isn't really ideal, but it is expected given the current state of session
history under Fission. It should hopefully be solved more gracefully when the
Fission-aware session history rewrite is done, but in the mean time, I think
we should just ignore the conflict, since it's expected.
Differential Revision: https://phabricator.services.mozilla.com/D48437
--HG--
extra : moz-landing-system : lando
The XBL test is being removed because it was the only remaining consumer of
xbl's implements="interfacename" in the tree, and was triggering QI on elements
for that codepath.
I've verified that a try run that MOZ_CRASHes when the C++ binding
QueryInterface implementation is invoked is green with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D48249
--HG--
extra : moz-landing-system : lando
We attempt to enforce the same (approximate) access checks to Location-based
navigation that we use for loads that use named targeting (e.g., via
window.open), so that a frame that can't be navigated via, e.g., window.open,
also can't be navigated via, e.g., window.parent[1].location = url. For the
in-process case, this is handled by a somewhat hidden call to
CheckLoadingPermissions() in nsDocShell::InternalLoad, where the former checks
whether the principal of whatever JS context happens to be on the stack
subsumes the principal of the target DocShell or any of its ancestors, and
blocks the load if it doesn't.
Since there is no JS context on the stack when we call into the DocShell
loading code in the cross-process case, the check is simply ignored.
So we need to instead do the check in BrowsingContext::LoadURI, where we
already have an explicit accessor, and can simply use the standard access
checks that we use elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D48443
--HG--
extra : moz-landing-system : lando