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
This adds back a MOZ_ENABLE_WEBRENDER define, which only controls whether or
not WebRender is enabled at runtime. The default behaviour is changed so that:
- if the user specifies --disable-webrender in the mozconfig, WebRender is
neither built nor enabled
- if the user specifies --enable-webrender in the mozconfig, WebRender is
built and enabled
- if the user specifies --enable-webrender=build in the mozconfig, WebRender is
built but not enabled, except on Android where it is neither built nor enabled
- if the user doesn't specify any of the above, the default behaviour is:
- on nightly/local builds, the same as --enable-webrender=build
- on other channels (e.g. aurora), the same as --disable-webrender
The net effect is that local/Nightly-automation builds will have WebRender
built-in but not enabled where possible (i.e. not Android). However the user
can override this behaviour via mozconfig options to either not build WebRender
at all, or to enable it in addition to building it.
MozReview-Commit-ID: IM7DdSHkIB
This will allow us to remove the PrefixMatch option from the public API version
of RegisterCallback/RegisterCallbackAndCall.
MozReview-Commit-ID: 6D0S35nv88Z
For Android we want to be able to set a global zoom factor that will scale any page where font inflation is not turned on.
Android makes the system font scale available as a float factor. For our purposes, converting this to a percentage based value and rounding to an integer is accurate enough and enables us to pass this value as a standard Gecko int preference. This means we can make use of the standard infrastructure for setting and retrieving Gecko-side preferences both from Java and JS (the latter during testing), as opposed to having to write custom JNI and C++/IDL helper functions.
To that effect, we implement a method for retrieving that setting via nsLayoutUtils, analogous to the current font inflation settings. Since we later want to clamp the effective text zoom resulting from that setting by zoom.minPercent and maxPercent, we add var caches for them in nsLayoutUtils as well.
MozReview-Commit-ID: Ler2YmwzImE
--HG--
extra : rebase_source : 6959c42267c1cb2b53804a609dda3d6d8b0bf14c
extra : source : 6a06ccede9eb54e4311e75e9f481d42d8c1f47a1
Open webcompat.com in new tab, similar to what "Report Site Issue" button does.
MozReview-Commit-ID: 1ESOY3upHgc
--HG--
extra : rebase_source : 3f55c6798671ad430e59f5954a177a22b4b7642d
We want the new MediaDecodeError messages to be forwarded to the front-end in
browser-media.js (even though they won't be handled just yet; an upcoming patch
will add the handling code).
This is limited to Nightly for now, like the "Report Site Issues" button,
because we forward URLs to webcompat.com (at the user's request).
And MediaDecodeWarning was not added, as it may cause too much annoyance, but
it is available for testers to get more diagnostics information if needed.
MozReview-Commit-ID: HPDpA1mg4HX
--HG--
extra : rebase_source : a9cb4096dd6221422d9acc2e4a08d99ed7daab5e
This change adds the names of the lists that Shavar will be serving to the Flash blocking prefs. This will allow those lists to control what domains are blocked or whitelisted.
MozReview-Commit-ID: BO20nwaQw1e
--HG--
extra : rebase_source : 84b3518746dc8cb4fffe01d97b9f1668cfc84bb7
This option turns on a frame counter that is shown in the top left corner via a
QR code. It was designed to be used in video recordings of B2G phones.
It no longer seems useful, so this patch removes it.
* * *
Bug 1357298 - Remove all traces of frame numbers and power from the profiler output. r=mstange.
--HG--
extra : rebase_source : 0ce87963ce375df64bb8d80ef2b5d40ea507bc7c
These prefs have been added close to two years ago:
dom.url.encode_decode_hash and dom.url.getters_decode_hash
The main reason for their existence was in case we encounter any web-compat issues. At this point the extra code is mostly useless, and flipping the pref may lead to crashes.
MozReview-Commit-ID: LhAHkYmv0TR
--HG--
extra : rebase_source : 8f2d50d5633496cf165b3925d952bb6475bce3e0
Consolas is narrower than Courier New, so we must adjust some tests to accommodate.
* Change some tests from generic 'monospace' to 'Courier New' to continue using previous font metrics.
* selectAtPoint.html no longer needs one of its Windows-only code paths because Firefox on Windows now selects the same text as it does on Mac and Linux.
* 323386-1.html's intermittent assertion failure (bug 718883) now appears to be 100% reliable on Windows, joining Linux and Android.
* size-1-ref.html reftest needs a little fuzz because the horizontal line of the test image's '4' character is ~1 pixel shorter than the reference image's.
MozReview-Commit-ID: EB5wzhG178U
--HG--
extra : rebase_source : e7aca6d16c255e45bef5dca93fff6c09bce787c4
As title, so no ifndef MOZ_RELEASE guard here.
If we discover some serious issues, we can always pref it off
on RELEASE channel.
MozReview-Commit-ID: 9ODz6SKdBeL
--HG--
extra : rebase_source : 30a277ae718186088004a3f4bd00b70441ab8b36
Iris Hsiao
Gerald Squelart
Valentin Gosu
Manish Goregaokar
Sebastian Hengst
Timothy Nikkel
Phil Ringnalda
Boris Zbarsky
Bill McCloskey
Carsten "Tomcat" Book
Joel Maher
Ting-Yu Lin
Mike Hommey
Kearwood Gilbert
Chris Pearce
Wes Kocher
Tom Ritter
bechen
Gabor Krizsanits
L. David Baron
Bob Owen
Masayuki Nakano
Martin Stransky
Gijs Kruitbosch
Stone Shih
Eric Rahm
Patrick McManus
Felipe Gomes
Munro Mengjue Chiang
Alastor Wu
Tobias Schneider
Kartikaya Gupta
Sotaro Ikeda
Chris Peterson
Amy Chung
Jonathan Watt
Mason Chang
Ethan Lin
Kershaw Chang
Ehsan Akhgari
Mats Palmgren
Florian Quèze
Astley Chen
Thomas Nguyen
Dragana Damjanovic
Andreas Farre
Jessica Jong
Blake Kaplan
Jeff Muizelaar
Jan Henning
Kirk Steuber
Nicholas Nethercote
Xidorn Quan
Robert Longson
Martin Husemann
Jeff Gilbert
Shawn Huang
David Anderson
Andrea Marchesini
Wei-Cheng Pan
Jeremy Chen
Neerja Pancholi
Jared Wein
Miko Mynttinen
Daosheng Mu