One of the last remaining differences when building Firefox on Debian
with all the changes we've done so far is that linking against the
system libc statically links some CRT objects. This causes massive
differences in the resulting binaries because of slight differences
in those objects (because they weren't compiled with the same compiler
and because they're not for the exact same glibc version)
In practice, their content difference don't cause any problem. If they
did, we wouldn't be able to run our builds on newer systems than those
we build them on. The only hypothetical risk would be to run on systems
with a glibc older than Debian 7's, but those already can't run Firefox
anyways (those systems don't have Gtk+3, which is a system requirement).
AFAICT, this is only an hypothetical problem anyways, even such systems
with Gtk+3 should be able to run those builds. Plus, this is a change
that will happen anyways when switching to Debian-based build images,
since they would be using the CRT objects from there. We're merely
making it happen earlier so that the differences from switching to
Debian-based build images are more tractable.
Note we only do this when building GCC on Debian, allowing to roll back
to CentOS-based toolchains by just switching back the toolchain jobs to
use the desktop-build docker image again.
When building on Debian (which we now are), this means we enable
.init_array/.fini_array.
When building on CentOS, this means no change. Which implies we could
roll back to CentOS-based toolchains by just switching back the
toolchain jobs to use the desktop-build docker image again.
This change causes massive differences in the resulting binaries because
of the offset differences, but practically speaking, there is no
difference. .init_array/.fini_array have been supported in glibc for 18
years.
... except libdmg-hfsplus. RedHat decided to patch libbz2 to have a
different soname, so a binary built on Debian can't run on
RedHat/CentOS. Ironically, a binary built on RedHat/CentOS can run
on Debian. While we could use some tricks to make libdmg-hfsplus built
on Debian work, at this point, it's not worth the effort. We can live
with libdmg-hfsplus being built on CentOS until the builds that use it
switch to Debian, which is imminent.
... and except mingw32-nsis. Sourceforce renewed their certificate last
week and somehow the corresponding CA is not yet recognized by the
ca-certificates in Debian wheezy (an update is underway but see below)
... and except wine, because it requires more 32-bits packages than can
be installed on the toolchain-build docker image. But all things
considered, the mingw32 builds don't need to be using the same docker
images as the linux builds, and they could be, like the android builds,
be based on a more recent build image. So the corresponding toolchains
can be built on a more recent version of Debian too.
Consequently, we keep all the mingw32 related toolchains on the
desktop-build image for now.
This moves the Safe Browsing notification banner into its own object, makes it aware of the current base domain,
and adds a function that's called when the location changes to determine if it should dismiss or not.
MozReview-Commit-ID: 31JQ4dUyFb4
--HG--
extra : rebase_source : e6d6589b0eef2d132fa355d4a6b36d2c429004af
extra : histedit_source : e385d8d7b609985ff29d8c9ff2d9ed55fc58bb85%2Ce8fb5de30938510a2b5d6a709b051e754a9ebc54
Remove the probe, and remove the cached value check.
Also remove dead code which relies on this sometimes-clamping glGet query.
MozReview-Commit-ID: JA1VgH8fLRB
Because Ubuntu 16.04 changed in a way that busts gl3 tests and we can't
update the desktop1604-test image anymore.
--HG--
extra : amend_source : bfa07f9f77990dd6915b8c92d218227436bc6fc4
The sNPObjWrappers table can contain entries for dead JSObjects that have not yet been finalised. We need to take care not to trigger mJSObj's read barrier for such entries since that will attempt to expose the object to JS and cause this assertion.
The patch does this by calling unbarrieredGetPtr() which avoids the barrier.
Note converting a TenuredHeap to bool and testing equality against a pointer don't trigger the barrier.
This patch reflects the following change to the Web Animations spec:
abf76745b5
MozReview-Commit-ID: A2GD1igUf5f
--HG--
extra : rebase_source : 8129f6386b144adebc3bf0320ca7d6bfbba7a2e9
Andrea Marchesini
Rofael Aleezada
Mike Hommey
Steve Pfister
Gijs Kruitbosch
Jan de Mooij
James Graham
Brindusan Cristian
Narcis Beleuzu
Nicolas Silva
Cameron McCormack
Margareta Eliza Balazs
Boris Zbarsky
Jeff Gilbert
Michael Froman
Noemi Erli
Ben Kelly
L. David Baron
Dragana Damjanovic
ffxbld
Andreea Pavel
Dragana Damjanovic dd.mozilla@gmail.com
Paolo Amadini
Jon Coppeard
Emilio Cobos Álvarez
Adrian Wielgosik
Jordan Lund
David Anderson
Brian Birtles
Tom Ritter
Ciure Andrei