In bug 1353123 it was decided to not extend this telemetry, so it will
expire in this release. Given that, and the fact that bug 1329336 has
disabled the feature already, it's time to remove the probe.
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or to call a function for side effects within an expression.
modules/libjar/nsZipArchive.cpp:651:25 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: 9PjB915D81f
--HG--
extra : rebase_source : c494c2f4a8291d6c08f02765e988c1fd14079e54
extra : source : 3643e37b615c4461b6a9359856731252acc36465
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
Smart string classes like nsCString are safer to use than raw |char*| strings,
and are typically easier to deal with as well.
MozReview-Commit-ID: 18C293zWrJw
--HG--
extra : rebase_source : 350191d4c3047fb38d18e8c6d9370cd059007861
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
Patch originally by Rahid Hasan. Updated by Akshendra Pratap Singh, jdm and Standard8.
MozReview-Commit-ID: F0edTCSsXzy
--HG--
extra : rebase_source : 7123a8162a4cdbcfb08f9a765d158e179c46b202
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
The patch also changes RemoteOpenFileChild::OpenNSPRFileDesc() so that it
cannot succeed with a null fd, so that checking just the return value is
sufficient.
--HG--
extra : rebase_source : cc40bbcf2a9991edc9d3da3fb624d27db50b4996
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
--HG--
extra : rebase_source : f82426e7584d0d5cddf7c2524356f0f318fbea7d
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204