Bug 1388851 adds hardware U2F support to Gecko; the instructions to test
involve flipping two prefs, but the common case will be using harwdare tokens,
so this patch makes users only haave to flip the "security.webauth.u2f" or
"security.webauth.webauthn" prefs as they choose.
MozReview-Commit-ID: 346120ZI8p4
--HG--
extra : rebase_source : fa491214d3b5532ea7e4843a9e52a19ab432a925
The algorithm names provided to the WebAuthn methods have to either be a
string, or (potentially) a WebCrypto object. Right now we only work with
strings, but there's no good reason to assert that, we can just let the
action fail.
This patch removes the assert to help out the fuzzing team.
MozReview-Commit-ID: 9dc8m0a2gZK
--HG--
extra : rebase_source : 649a7f4928679405fe445ac533eee2cfccaedd25
Englightenment closes fd 0 on child processes and so pipe() can return a zero fd.
MozReview-Commit-ID: 5d9xQXgwgfv
--HG--
extra : rebase_source : c31aa7ce731ba325993f463b79b446ae67c932dd
Bug 1364159 introduced an optimization that attempted to avoid reading from the
user's cached certificate database as much as possible when building a verified
certificate chain. Unfortunately this had the side-effect of not preferring root
certificates in path building, which can result in unnecessarily long chains
(which rather defeats the purpose, since it means more signature verifications).
This patch reverts the functionality changes from that bug but keeps the test
that was added (the test didn't directly test the functionality changes - it's
more of a check that path building will query the cached certificate db when
necessary).
MozReview-Commit-ID: I56THTLUytH
--HG--
extra : rebase_source : 7db9597e25b98942450840519d707046cc660781
CLOSED TREE
--HG--
extra : amend_source : 84120d6bacb5d72a9fbe41e4c3b405d63825da7c
extra : histedit_source : 8320c2193761b745f10850055ee74a3c9ac73615%2Cfbc2a28d8c5004a53305ef858ca5aea4245691e0
Add a `window` parameter to all Prompt.jsm usages, so the prompt will
appear in the correct window. This includes HelperAppDialog.js, which
was preventing the download chooser dialog from appearing in a custom
tab window.
The patch also moves `getActiveDispatcher` from GeckoViewPermission to
GeckoViewUtils, and makes several improvements to `getChromeWindow` and
`getDispatcherForWindow`. Prompt.jsm now uses the active
WindowDispatcher in the fallback scenario where we don't have a window.
MozReview-Commit-ID: KpAFMCZzQZp
Icons apparently doesn't fade images, however, so it looks bad. Also, we try to
request the image each time we bind, so scrolling up and down will create
additional pop-in, which also sucks.
MozReview-Commit-ID: 246pokTMFl7
--HG--
extra : rebase_source : 8cb2750225d2e0331b1cfe25e02c766dd631e565
<!-- Please describe your changes on the following line: -->
Allow paint worklets to draw to a border.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#17451.
- [X] These changes do not require tests because the existing css-paint-api test check this (but annoyingly, all fail for other reasons)
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: a5282cabe04ac836458652bcb2b5e40214d36390
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6924fe28fb30379d26e2be76e73a1521ea16239c
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
CentOS 6 is pinned to glibc 2.12, but newer Android build-tools (like
aapt) require glibc 2.14. It's not possible to safely upgrade CentOS
6 distributions to glibc 2.14.
CentOS 7 is pinned to glibc 2.17, which is new enough for newer
Android build-tools. However, I had great difficulty bringing forward
our existing centos:6 Docker image to centos:7. In particular,
installing recent enough Mercurial, git, Python, and pip versions was
difficult enough that I elected to not pursue this approach.
Instead, I've elected to follow glandium's suggestion from
https://bugzilla.mozilla.org/show_bug.cgi?id=1370119#c5: base on
Debian with snapshots.debian.org for reproducibility.
The most significant changes here:
- using Debian's snapshots repository
- using Python and related tools provided by Debian and baked into the
build image
- using the JDK and JRE provided by Debian and baked into the build
image, rather than versions from tooltool (or eventually a toolchain
build)
Moving the builds over to use this image will follow in the patches
ahead.
The name `android-gradle-build` is an accident of history; let's rename it
before we attempt major surgery on it.
--HG--
rename : taskcluster/docker/android-gradle-build/Dockerfile => taskcluster/docker/android-build/Dockerfile
rename : taskcluster/docker/android-gradle-build/README.md => taskcluster/docker/android-build/README.md
rename : taskcluster/docker/android-gradle-build/REGISTRY => taskcluster/docker/android-build/REGISTRY
rename : taskcluster/docker/android-gradle-build/VERSION => taskcluster/docker/android-build/VERSION
rename : taskcluster/docker/android-gradle-build/buildprops.json => taskcluster/docker/android-build/buildprops.json
rename : taskcluster/docker/android-gradle-build/dot-config/pip/pip.conf => taskcluster/docker/android-build/dot-config/pip/pip.conf
rename : taskcluster/docker/android-gradle-build/oauth.txt => taskcluster/docker/android-build/oauth.txt
Parts of Spidermonkey expect the bytecode length to always be non-zero.
Bug 1399373 shows crashes when this assumption fails. This patch moves
the check closer to source of error.
MozReview-Commit-ID: 8JROF2KCrNx
This is an exception from the usual NSPR release upgrade process and essentially an agreed temporary fork, which will be undone for Firefox 58.
This change isn't causing any harm, because the temporary API is used only for Windows, and only accessed using dynamic symbol lookup, so it will not cause any issue on operating systems that use a system-wide install copy of NSPR without the symbol.
UPGRADE_NSPR_RELEASE
Rather than using left-hand-side at all times (which can go over the edge of the window
in some cases) this uses left or right-hand-side panels, always opening towards the
center of the window.
MozReview-Commit-ID: EvjDmKR1G5A
--HG--
extra : rebase_source : 12046edc24b564e035dff68a5e34bce3ff5fd507