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
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
--HG--
extra : rebase_source : 8939e453c2277caa4a90123ae09bb542aaa421ed
Per discussion on dev.platform, this is risk-prone, and we want more
time baking on nightlies and early betas to see if it causes problems.
MozReview-Commit-ID: CaprjWxYfbC
--HG--
extra : rebase_source : d8adf27d78ea258af88d4f05d87cd0caf9c5bdb9
The media prefs "media.decoder-doctor.decode-{errors,warnings}-allowed" list
which decode issue codes will show the "Report Site Issue" notification.
Default: NS_ERROR_DOM_MEDIA_DEMUXER_ERR and NS_ERROR_DOM_MEDIA_METADATA_ERR,
which are the kinds of errors we currently care most about, and have more
chance to fix.
MozReview-Commit-ID: JbY2pwv4TXP
--HG--
extra : rebase_source : 65809f5eb3ace85e25b01c0d1cdfdd068c467ca0
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
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
This is regression-prone, so dev.platform discussion concluded we want
it behind a pref. We might turn the pref off for beta and/or release
for now as well.
MozReview-Commit-ID: 2H2et3RElZx
--HG--
extra : rebase_source : baf7e679ca1ee16016666d7697990c4f64ecf83e
After this patch is introduced, url-classifier will return merged classify result
from V2 and V4.
--HG--
extra : rebase_source : 1940f8617547878b87a5808479ef9d46e6722a92
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
This adds a PrefName wrapper that allows use to avoid copying the pref name
string in the fast root pref branch case, but also allows to create a new
string in the slower non-root pref branch case. By creating a new string we
avoid the odd behavior of mutating the pref branch name with each retrieval.
MozReview-Commit-ID: HGCLbpGmKrr
This updates test_libPrefs.js so that it actually runs all the observer
portion of it's tests. Previously the observer callback would get hit before
the next do_test_pending call could be run, thus causing the test to end.
An additional test was added to confirm that registering for multiple prefs on
a non-root pref branch works as intended.
If 'media.playback.warnings-as-errors' is true, demuxing and decoding warnings
(i.e., non-fatal errors) will be treated as errors, causing playback to fail.
Currently set to false by default.
This could be later changed to catch and diagnose more issues.
MozReview-Commit-ID: BTaZ6TbIbNG
--HG--
extra : rebase_source : bacc24a46f588dd344e6d46178ae2d2c58882fcb
The racing algorithm is quite simple at this point:
If racing is enabled, the request is allowed to hit the network, and the cache queue size is bigger than a certain threshold, then we trigger the network right before we query the cache.
MozReview-Commit-ID: JklG4P1eRyO
They have generic names, and are potentially conflicting with
in-tree headers with the same name (which is true for at least port.h).
There aren't enough users of brotli to want to avoid LOCAL_INCLUDES
in the directories that use it.
--HG--
extra : rebase_source : 82531ac5961ad80e1b3d0c1484a2f146be194411
woff_out.h includes port.h (actually, worse, "./port.h"), and in
dist/include, port.h is actually *not* the one from woff2...
We've just been lucky it's worked so far.
--HG--
extra : rebase_source : 65537c1f6c0ba540e0c93ef2c8ba587e5903d273
This gives us simpler code, and eliminates some extra frame copies.
MozReview-Commit-ID: 10N0O9Pn0Kw
--HG--
extra : rebase_source : 8c99178ac94b3f580772598766b2e701da7cfe2c
extra : intermediate-source : 6d6877aa1d1905a2bc05dbf77bb4122af1722719
extra : source : 05f80a9025abea168ca2ee649316422418d08dc0
Makes transfer of samples between the content and CDM processes use shmems.
The Chromium CDM API requires us to implement a synchronous interface to supply
buffers to the CDM for it to write decrypted samples into. We want our buffers
to be backed by shmems, in order to reduce the overhead of transferring decoded
frames. However due to sandboxing restrictions, the CDM process cannot allocate
shmems itself. We don't want to be doing synchronous IPC to request shmems
from the content process, nor do we want to have to do intr IPC or make async
IPC conform to the sync allocation interface. So instead we have the content
process pre-allocate a set of shmems and give them to the CDM process in
advance of them being needed.
When the CDM needs to allocate a buffer for storing a decrypted sample, the CDM
host gives it one of these shmems' buffers. When this is sent back to the
content process, we copy the result out (uploading to a GPU surface for video
frames), and send the shmem back to the CDM process so it can reuse it.
We predict the size of buffer the CDM will allocate, and prepopulate the CDM's
list of shmems with shmems of at least that size, plus a bit of padding for
safety. We pad frames out to be the next multiple of 16, as we've seen some
decoders do that.
Normally the CDM won't allocate more than one buffer at once, but we've seen
cases where it allocates two buffers, returns one and holds onto the other. So
the minimum number of shmems we give to the CDM must be at least two, and the
default is three for safety.
MozReview-Commit-ID: 5FaWAst3aeh
--HG--
extra : rebase_source : a0cb126e72bfb2905bcdf02e864dc654e8340410
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : 8%8Ci%CC%EA%0F%CF%C7%3E%F1%93%F5%C9%ED9%84%F9%3Evx
This patch sets all "font.name.*" prefs to empty string which will mean "default".
And also existing values of "font.name.*" prefs are moved to the first item of "font.name-list.*". The first item should be used when "font.name.*" is "default".
MozReview-Commit-ID: JxgiCSc1mka
--HG--
extra : rebase_source : 7e87916cebb7735b899fa1bc789b86d2e80b95f8
Add two new prefs (widget.chrome.allow-gtk-dark-theme and widget.content.allow-gtk-dark-theme) to enable dark
themes in chrome and content when e10s is enabled.
When e10s is disabled then widget.chrome.allow-gtk-dark-theme controls both chrome and web content settings.
That may be a bit confusing but it's going to be here for two releases only (Firefox 57 is going to have e10s enabled by default) and actually matches recent state when only one ENV pref is used for both chrome and web content.
The existing MOZ_ALLOW_GTK_DARK_THEME environment variable is still considered, but, now is like widget.chrome.allow-gtk-dark-theme, no longer affecting separate content processes.
MozReview-Commit-ID: CCwriA66CNj
--HG--
extra : rebase_source : 93e9a504af3e7570f82ddaf0890e374fe939e919
This should ride the train at 57. Until then, we should keep watching the feedback from testers.
This patch changes Japanese default fonts as:
Serif => "Yu Gothic" if available, otherwise, "MS PMincho".
Sans-serif => "Meiryo" if available, otherwise, "Yu Gothic" if available. Finally, "MS PGothic".
Note that on non-Japanese Windows, only "Yu Gothic" may be installed.
Additionally, this patch changes font.name-list.*.ja as getting similar result to default font settings.
MozReview-Commit-ID: AsT1DaXY9dA
--HG--
extra : rebase_source : 8a9d379d6b2ebcd067ac2b6ad54117152b86673a
Due to Windows doesn't support dnd in the pen message handler, we can't handle and consume WM_POINTER* to fire WidgetMouseEvent. On the other hand, we can't get some pen related attributes from Windows mouse messages. This patch gets and caches the attributes by handling WM_POINTER* but not fire WidgetMouseEvent to support dnd and pen related attributes. When handling the subsequent Windows mouse messages, we use the cached attributes to fire WidgetMouseEvent. Considering we might need to use WM_POINTER* someday, use a preference to control the behavior.
MozReview-Commit-ID: 5E60KO1zo0W
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : %8DM%88%E8%B7%B4%D8a%D6%F5%3F%9B%DC%09X%F3%7C%98%DE%21
This removes all the code for add-on performance watching from the
perfmonitoring component. This should mean that for add-on
compartments, we no longer trigger jank or CPOW monitoring in the JS
engine. This should result in minor performance improvements. As a
result, about:performance no longer reports on add-on performance
(but still reports on web page performance).
It also removes the AddonWatchers.jsm module and the related Nightly-
only UI (disabled in the parent commit) and strings. This UI wasn't
ready for release, there wasn't sufficient data it was creating
value for users, and there was some evidence that it didn't always
correctly identify the cause of performance issues, thus potentially
leading to user confusion or annoyance. Removing it therefore seemed
the right thing to do.
MozReview-Commit-ID: LsRwuaUtq6L
--HG--
extra : rebase_source : 92d4b775a7a7cbb5793e74eea471be81be974dda
Put this feature only on Aurora and Nightly until it's stable enough.
MozReview-Commit-ID: 4jl9gZO3wtt
--HG--
extra : rebase_source : 952f2718d77ff3bc48a92152fbfa290798db33c6
This allows us to remove the #ifdef MOZ_ENABLE_WEBRENDER for the advanced layers
prefs from all.js. As additional advanced layers are turned on for webrender (or
non-webrender) they can be converted into override prefs without affecting the
call sites.
MozReview-Commit-ID: F9tMc23ow8A
--HG--
extra : rebase_source : 2244cb000711496ce5b7f1b50ef0314e1c312d94
Chris Peterson
Arthur Edelstein
Carsten "Tomcat" Book
Valentin Gosu
Jim Porter
Aryeh Gregor
Gerald Squelart
Mike Hommey
Sebastian Hengst
Francois Marier
DimiL
Markus Stange
Chris Pearce
Iris Hsiao
Andrew Swan
Jeff Muizelaar
Shawn Huang
JW Wang
Wes Kocher
Johann Hofmann
Bobby Holley
Florian Queze
Phil Ringnalda
Tobias Schneider
Masatoshi Kimura
Kearwood Gilbert
Honza Bambas
Patrick McManus
Petr Sumbera
Nathan Froyd
Jim Mathies
Eric Rahm
Fischer.json
Manish Goregaokar
Timothy Nikkel
Boris Zbarsky
Bill McCloskey
Joel Maher
Ting-Yu Lin
Tom Ritter
bechen
Gabor Krizsanits
L. David Baron
Bob Owen
Masayuki Nakano
Martin Stransky
Gijs Kruitbosch
Stone Shih
Felipe Gomes
Munro Mengjue Chiang
Alastor Wu
Kartikaya Gupta
Sotaro Ikeda
Amy Chung
Jonathan Watt
Mason Chang
Ethan Lin
Kershaw Chang
Ehsan Akhgari
Mats Palmgren