For obscure linkage reasons, we need all the replace-malloc symbols
being passed to the linker to tell it to allow them being undefined.
That list actually duplicates what's in malloc_decls.h somehow, and
every time we add an entry point, we end up having to modify those two
files (and others, addressed in different bugs), which is suboptimal.
So we generate the list of those symbols from malloc_decls.h.
--HG--
extra : rebase_source : 50156c6dda5601a6437f94a753400ec4ed9c8343
There's an intermittent that is showing up now that test_register_sign.html
checks state.attestationCert.verify(); to ensure hte SoftToken's certificate
is valid. This patch prints the offending certificate when it's encountered,
to help diagnose the root cause.
MozReview-Commit-ID: 4QSobq9fBGK
* The start padding should match the 12px defined for nearby toolbarbuttons:
.subview-subheader, panelview .toolbarbutton-1, .subviewbutton, .widget-overflow-list .toolbarbutton-1
* Add override for OSX which uses 18px for this padding
* Adjust margin for the right/end icon in banner items
MozReview-Commit-ID: 81u97Wf8qXr
--HG--
extra : rebase_source : bcdfce3a2d0cd66359df45b3372191268defbde5
This allows data like screen position to be persisted in the xul store for the document
MozReview-Commit-ID: 4vdbkneckXh
--HG--
extra : rebase_source : b8ae9f50bcbd152e9ee9d9462a81a56661da40cb
Small fixes to ride-along in this bug:
* Use localized ellipsis in ActionBarHandler if available.
* Fix one situation where the FormAssistPopup fails to hide.
* Handle an error case in FormAssistant.
MozReview-Commit-ID: 9EZhPnS5h3E
--HG--
extra : rebase_source : a05c13c242158cc1396912378b6f529eea38b0de
Use the universal DoorHanger API from Prompt.jsm to show the login
doorhanger from any window. Also, refactor parts of LoginManagerPrompter
to use Services.jsm if possible.
MozReview-Commit-ID: 3cnzeT0RNgR
--HG--
extra : rebase_source : 70a926fec8d15c70a75f6afe771e973fd62fe9c9
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
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.
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.
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
