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
