As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: Gcq3Qna02iB
--HG--
extra : rebase_source : 2ccaa22eb85280cc8d322df87fb759e8dff67cf1
With all the things that still depend on all the variables derived from
--host and --target in both old-configure and moz.build, we still need
to keep variables such as OS_ARCH, OS_TARGET, CPU_ARCH, OS_TEST, etc.
Eventually, we'd settle on the output of split_triplet.
This /tries/ to preserve the current values for all these variables,
while also trying to make things a little more consistent. It also
effectively rejects OSes such as HPUX or AIX, because it is unclear
the decades old accumulated scripts related to them still do anything
useful, and we might as well have them start again from scratch, which,
in the coming weeks, will be even easier.
The proper fix is to fix the underlying problem. However, I haven't
touched C++ in months and I'm lazy. So I'm going for the quick fix
so Visual Studio 2015 rollout is unblocked.
MozReview-Commit-ID: 14cZCGPkx0V
--HG--
extra : rebase_source : 91ec0d461e4e14e1fa3b641b3ca7f169e0901b11
extra : source : 9e5f9917fe1a7bef9585966959d516636d7ee6ac
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 759e9c5a7bb14f14a77e62eae2ba40c085f04ccd
This will make sure that window.scrollbars correctly reflects the respective
chrome flags in e10s mode.
We also update nsXULWindow::SetContentScrollbarVisibility() to the new
nsContentUtils helper. That code is responsible for doing this work in the
single process case.
Follow the DataView functions and use Tonumber to coerce index arguments on the
load/store functions. Throw a RangeError when we see a non-integer index or a
number outside the range of the array.
See https://github.com/tc39/ecmascript_simd/issues/328
MozReview-Commit-ID: IpHkfPyywU0
Virtualenv will sometimes find a different executable from its sys.executable on OS X,
causing a check in the build system comparing filesizes between sys.executable and virtualenv
python to fail, resulting in clobbering and re-building the virtualenv every time the virtualenv
is activated, causing the build backend and more to be re-built.
Instead of checking file sizes directly, this commit causes us to record the size and version of the
Python executable that created the virtualenv. If the Python executable checked is not the virtualenv
Python, or we have a different version than was used to create the virtualenv, then the virtualenv is
considered to be out of date.
MozReview-Commit-ID: KmrVfQCtbS3
--HG--
extra : rebase_source : d2b87325e10da6dfcd74f8b0d2ef7c0efb71595b
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
This is left over from the pre-SurfacePipe code that interacted directly with the Downscaler. It was calculating the size of the surface for the Downscaler to use, and then the Downscaler would handle putting transparent pixels inside that surface (and outside the framerect).
--HG--
extra : rebase_source : aad384fa8589f291254f0a18537a5d6674487182
I believe this is useful for cases like having logical properties in the
UA style sheet that are commonly overridden (e.g., margins on lists).
MozReview-Commit-ID: KxojbfMYq0f
Tooru Fujisawa
Gregory Szorc
Mike Hommey
David Keeler
Sebastian Hengst
Daniel Holbert
Eric Faust
Alexander Surkov
Terrence Cole
Mike Shal
Jason Orendorff
Blake Winton
Wes Kocher
Ehsan Akhgari
David Anderson
Jakob Olesen
Chris Manchester
Nathan Froyd
Kartikaya Gupta
Rail Aliiev
Timothy Nikkel
Jonathan Kew
Edwin Flores
Blake Kaplan
Nicolas B. Pierron
Andrea Marchesini
Myk Melez
Marco Castelluccio
L. David Baron