Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
This appears to have been "broken" since bug 510844, for some value of
broken where it doesn't actually cause any problem in practice because
of how zlib behaves.
That is, in practice, we always still have input to process when there's
pending output. But while that's true with zlib, that's not necessarily
true for other decompressors (e.g. brotli).
--HG--
extra : rebase_source : 7572139f8e2b3df8c6b68123c0a14524dddb3faf
They are, in fact, the same version already, built from the same version
of clang-static-analysis-linux64.json, but one comes from a now expired
try build, and the other from a build on mozilla-central, that can still
be traced down:
https://tools.taskcluster.net/task-inspector/#Ro1bUCv4Svu2OWuQsOF_hA/0
--HG--
extra : rebase_source : 776314cecb3cba7043a02f4e1f2f4feb4b51731c
In Bug 1311935, We change positive/negative cache duration from milli-second to second.
But the value doesn't covert back to milli-second when store to telemetry(telemetry use
milli-second).
MozReview-Commit-ID: KR6xn9pwhUd
--HG--
extra : rebase_source : 378149dc29d61cbca31b8aa913df946ceff556f3
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: 77pLXhdbpPp
--HG--
extra : rebase_source : 7201f230299c571d6c3a86ce650d6852c43e0943
Since the allow list contains both hostnames and certificate hashes, it makes sense
to use it on all platforms.
MozReview-Commit-ID: 1icRFYhhnAY
--HG--
extra : rebase_source : bcb6113090546cdca2b4f2dd120db98ffb511b0d
Add the aarch64-linux-android libstd to the android-cross
repackage of the upstream rust 1.16.0 stable builds.
MozReview-Commit-ID: gmZL7QCodQ
--HG--
extra : rebase_source : dc4072c3214188195aa6abda939d550df4e617d9
MozReview-Commit-ID: Kp8x5o66nrY
I want AccessibleHandler.dll to use different UUIDs based on release channel.
The way I was doing it before wasn't working correctly because I also wanted
local builds to have their own set of UUIDs vs our regular Nightly/Beta/Release
builds.
I also want the beta channel to have its own set of UUIDs that are distinct
from release.
I'm using MOZ_UPDATE_CHANNEL to distinguish between the channels when
NIGHTLY_BUILD and BETA_OR_RELEASE are insufficient.
--HG--
extra : rebase_source : 8cb28a22a3cac16fb743a8fe81db5e120c1fdf6d
I'm taking another kick at this. Since glandium's negative review of
older patches a year ago, generate_build_config.py landed (with your
r+, gps). These patches extend that mechanism to generate
AndroidManifest.xml. This sets the stage for that.
This is all in service of Bug 1355625, which will need the
generate_build_config.py extension point to do things that the
preprocessor cannot handle: generating Java code, copying resource
files, and merging resource XML declarations.
MozReview-Commit-ID: AcyC3CBMQl1
--HG--
extra : rebase_source : c379b07de4b9f9b4bfe53e6a0adac13f08a71c73
Infer dumps a whole load of temporary output, in addition to the actual
report, under infer-out. We don't want to accidentally commit that.
MozReview-Commit-ID: Jtpt4rhDwF5
--HG--
extra : rebase_source : 49c37e3557aaa83a8ab430a6316d624e71df1a4a
Bump the version number to match what is currently published.
MozReview-Commit-ID: 8r8otQQBqBo
--HG--
extra : rebase_source : 1b7daac6b2852117ae08927fd5a09b2a7650d683
Increases WPT wdspec timeouts to more realistic values. Because wdspec
tests interact with the browser from an OOP program, they require more
time to run. Interactive browser tests are also known for generally
being more expensive to run.
25 seconds for the default timeout and 120 seconds for the long timeout
are values picked out of the air and likely needs to be further refined
in the future. It is however the current belief that this moves us in
the right direction.
Further improvements to this approach may involve letting wdspec tests
define timeouts on a per-file or a per-test function level through the
use of pytest-timeouts, but this is purely speculative at this point.
It is the current recommendation to adjust the number of tests and the
runtime duration of the tests in a file according to these new defaults.
MozReview-Commit-ID: 4I3Xz9G6lzv
--HG--
extra : rebase_source : 5ec7439e736dc9978828e420bd31195e63130fed
Certain test types have a need for other defaults than the
wpttest.DEFAULT_TIMEOUT and wpttest.LONG_TIMEOUT values. This patch
changes wptrunner to define default- and long timeouts on a test type
level. This allows a test type to override the default durations defined
in the abstract Test.default_timeout and Test.long_timeout.
Concrete classes, such as ReftestTest and WdspecTest, may override these
class properties.
MozReview-Commit-ID: IS6df5vuIDC
--HG--
extra : rebase_source : a3f37d4524902f2b0d54e14126b57da327f0ec06
- Also removed some now redundant calls to VRHMDSensorState::Clear()
MozReview-Commit-ID: Kkbvkn3XAP4
--HG--
extra : rebase_source : 0daecf8ad2f4baa8f3d199c65dc7c0cbeb4aceae
I looked at the wrong try push before pushing this change to inbound. Backing it
out hopefully before it turns too many pushes orange.
MozReview-Commit-ID: 5cREsyfWrmb
When the dom.w3c_touch_events.enabled pref is set to "2" (autodetect) on Win/Linux,
it checks to see if the hardware supports touch events, and only enables the
DOM touch APIs if so. However, even if the hardware supports touch events, we
might have e10s or APZ disabled for other reasons, and in those cases we don't
actually turn on touch support in the widget (nsBaseWidget::RegisterTouchWindow
will not be called). So in those cases the widget will never actually dispatch
touch events, and the DOM touch APIs shouldn't be exposed either. This patch
implements this by checking the APZ state when deciding whether or not to
expose the DOM touch APIs.
MozReview-Commit-ID: EIvJh030b0X
Mike Hommey
Mark Banner
DimiL
Jed Davis
Matheus Longaray
Francois Marier
Jared Wein
Sebastian Hengst
Dão Gottwald
Ralph Giles
Aaron Klotz
Nick Alexander
Andrzej Hunt
Andreas Tolfsen
Ray Lin
Gregory Moore
Wes Kocher
Kearwood Gilbert
Michael Layzell
Kartikaya Gupta
Jeff Muizelaar
Lee Salzman
sotaro
Kris Maglione
Paul Rouget
Srivatsav Gunisetty