Note that we also drop the dead optional aReusableSheets argument from
the async parsing path, since it was always null.
MozReview-Commit-ID: KddpGFdaqEe
These prefs are on by default now, and so there's no point in keeping them as
override prefs.
MozReview-Commit-ID: Gzs65oS9koD
--HG--
extra : rebase_source : 89d52f7992a0e87f60673f3b7bd6efad627fd040
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : ee6acf7d046e8ce6e18a53988a4ea308b8d4d44f
This makes the APZ sampler thread be the render backend thread whenever
webrender is being used (not just when async scene building is enabled).
MozReview-Commit-ID: L9lmopd3pe7
--HG--
extra : rebase_source : a23793bf704a0bf3bc7ba6568ecfe5faa5720415
It can happen often where we reuse the front buffer for a long paint, and then
the next frame we see that it is still locked, and need to allocate a new buffer
from the texture pool. If this happens we don't need to repaint the new buffer
because the old buffer is still around, but we do need to copy it over and
upload it to texture sources. It seems better to just hold onto the back buffer
and let it accumulate more invalid regions.
MozReview-Commit-ID: 2DQjwAX7ZmM
--HG--
extra : rebase_source : 3077952d3ef56deea6af68492f71bb114d96d84a
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly.
However, some web apps actually broken with the standardized behavior. For
protecting testers from known broken web apps, this patch introduces a
blacklist to take the traditional behavior under specific domain (and path in
it, optionally). Currently, docs.google.com and mail.google.com are set by
default.
MozReview-Commit-ID: HSrYX8LUB0p
--HG--
extra : rebase_source : a2677d07410af289534db051767543a25c9a957a
And a builtin function to test if wasm gc is enabled or not, to make testing
easier.
--HG--
extra : rebase_source : 0e608756d0c5f0231ba31af482c5e343a7119465
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
This commit only introduces the concept and the functionality of retrieving the
values from the two new related prefs. Still no actual functionality change is
involved.
MozReview-Commit-ID: 2Gl3Wqdo6jL
--HG--
extra : rebase_source : bf30483e3e32829a5d6fd927740471ba348448f9
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
This feature is B2G only. Remove it to make AccessibleCaret simpler to
maintain.
MozReview-Commit-ID: 7JZw5XtaUeU
--HG--
extra : rebase_source : aba249d361723feeaf769a3b802564dbcd6ca9ea
The new StaticPrefs machinery means that StylePrefs can be removed.
Note that this approach mirrors all static prefs into Rust, but I have only
updated structs.rs for the prefs that Stylo uses.
On a CLOSED TREE, since a sheriff closed the tree while I was about to land this
via autoland.
MozReview-Commit-ID: G1SY0987WJ7
This removes our ability to detect when an unnecessary override is occurring,
but it's necessary for Thunderbird to work.
MozReview-Commit-ID: GZYLnEEVuvd
--HG--
extra : rebase_source : ff3f7163252176d78ecf11589cebeae99f987985
Currently VarCache prefs are setup in two parts:
- The vanilla pref part, installed via a data file such as all.js, or via an
API call.
- The VarCache variable part, setup by an Add*VarCache() call.
Both parts are needed for the pref to actually operate as a proper VarCache
pref. (There are various prefs for which we do one but not the other unless a
certain condition is met.)
This patch introduces a new way of doing things. There is a new file,
modules/libpref/init/StaticPrefList.h, which defines prefs like this:
> VARCACHE_PREF(
> "layout.accessiblecaret.width",
> layout_accessiblecaret_width,
> float, 34.0
> )
This replaces both the existing parts.
The preprocessor is used to generate multiple things from this single
definition:
- A global variable (the VarCache itself).
- A getter for that global variable.
- A call to an init function that unconditionally installs the pref in the
prefs hash table at startup.
C++ files can include the new StaticPrefs.h file to access the getter.
Rust code cannot use the getter, but can access the global variable directly
via structs.rs. This is similar to how things currently work for Rust code.
Non-VarCache prefs can also be declared in StaticPrefList.h, using PREF instead
of the VARCACHE_PREF.
The new approach has the following advantages.
+ It eliminates the duplication (in all.js and the Add*VarCache() call) of the
pref name and default value, preventing potential mismatches. (This is a real
problem in practice!)
+ There is now a single initialization point for these VarCache prefs.
+ This avoids need to find a place to insert the Add*VarCache() calls, which
are currently spread all over the place.
+ It also eliminates the common pattern whereby these calls are wrapped in a
execute-once block protected by a static boolean (see bug 1346224).
+ It's no longer possible to have a VarCache pref for which only one of the
pieces has been setup.
+ It encapsulates the VarCache global variable, so there is no need to declare
it separately.
+ VarCache reads are done via a getter (e.g. StaticPrefs::foo_bar_baz())
instead of a raw global variable read.
+ This makes it clearer that you're reading a pref value, and easier to
search for uses.
+ This prevents accidental writes to the global variable.
+ This prevents accidental mistyping of the pref name.
+ This provides a single chokepoint in the code for such accesses, which make
adding checking and instrumentation feasible.
+ It subsumes MediaPrefs, and will allow that class to be removed. (gfxPrefs is
a harder lift, unfortunately.)
+ Once all VarCache prefs are migrated to the new approach, the VarCache
mechanism will be better encapsulated, with fewer details publicly visible.
+ (Future work) This will allow the pref names to be stored statically, saving
memory in every process.
The main downside of the new approach is that all of these prefs are in a
single header that is included in quite a few places, so any changes to this
header will cause a fair amount of recompilation.
Another minor downside is that all VarCache prefs are defined and visible from
start-up. For test-only prefs like network.predictor.doing-tests, having them
show in about:config isn't particularly useful.
The patch also moves three network VarCache prefs to the new mechanism as a
basic demonstration. (And note the inconsistencies in the multiple initial
values that were provided for
network.auth.subresource-img-cross-origin-http-auth-allow!) There will be
numerous follow-up bugs to convert the remaining VarCache prefs.
MozReview-Commit-ID: 9ABNpOR16uW
* * *
[mq]: fixup
MozReview-Commit-ID: 6ToT9dQjIAq
- The first two SYNTAX HINTS are wrong, and citing the syntax is more useful
than specifying a single example of what isn't allowed.
- The sentence about #ifdefs is wrong. (#ifdefs appear all throughout, and
prefs are only specified once.)
- I chose a better example file.
MozReview-Commit-ID: JyYFyutqrFD
Currently all pref initialization is done from file, but soon we will also be
initializing prefs from code compiled into the binary. The new name encompasses
both cases.
MozReview-Commit-ID: 5g0jfjHTvnE
--HG--
extra : rebase_source : 938b33626594992846377c5d1b684b1dbf96cb57
Some of the definitions are needed for the headers removal in
following patches.
MozReview-Commit-ID: BCj7U7RgBLj
--HG--
extra : rebase_source : e8e437f76c4db6ec930ea0481b6c1a38129a5477
extra : source : a1c42220e5070fa4beea438859ab0daec3f3fe7b
This change was supposed to happen in the previous patch from this bug.
MozReview-Commit-ID: 93dFyFBbWwO
--HG--
extra : rebase_source : d348dd4a4140f4482bcf493346cf58bd5ef6475b
All pref-modifying operations now only occur in the parent process. Hooray!
MozReview-Commit-ID: GDVsda4rw5f
--HG--
extra : rebase_source : 4f8484f0751212120078b3ba1a32930bc9c5ed8a
It'll be set via the normal parent-to-child pref setting process.
MozReview-Commit-ID: By4mG7brc55
--HG--
extra : rebase_source : 480a289edf81b36395619a3bb9f5a1e065cb33d8
All prefs that need to be sent to a new content process are now put into the
shared memory segment, and they are identified by the pref name instead of an
index into a list. The old IPC used at process startup (in XPCOMInitData) is
removed.
Benefits:
- It removes the need for the early prefs list
(dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly
and often trips people up (e.g. bug 1432979, bug 1439406).
- Using prefnames instead of indices fixes some fragility (fixing bug 1419432).
- It fixes the problem of early prefs being installed as unlocked default
values even if they are locked and/or have user values.
MozReview-Commit-ID: FRIzHF8Tjd
Previously we had disabled them in content pages on Nightly and Early Beta,
now we're ready to let this ride the trains in 61.
We're going to land this ahead of Bug 1446470 which is specifically about
url-prefix().
MozReview-Commit-ID: AGDHt1snyjU
--HG--
extra : rebase_source : 7f26f898ff887cd4915d5b5a7bd7c3de0476a803
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
These statistics will be used by browser tests to analyze frequently accessed
preferences so that we can recommend using preference observers instead.
MozReview-Commit-ID: 9uZnwmjZL4U
--HG--
extra : rebase_source : c8a8e624f06dfff12d8503a7c8299a0051192339
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
We no longer support legacy extensions with e10s shims, and the only remaining
uses that matter are in-tree test harnesses, which have been fixed. This flag
no longer serves a purpose.
MozReview-Commit-ID: EdCNqF4MttN
--HG--
extra : rebase_source : 0fef334354faa7541628614cb964a29faaa9df41
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
- gfxVRExternal Enables other processes to present
real or simulated VR hardware to Firefox.
- This functionality is disabled by default, under
dom.vr.external.enabled.
- VRDisplayInfo, VRControllerInfo, and associated
structs have been restructured to ensure internal
state is not exposed via shmem interface.
- Some refactoring to convert structs to
POD types, enabling them to be located
in shmem and be memcpy'd.
- Work needed before unpreffing marked
with "TODO" comments.
MozReview-Commit-ID: FbsusbxuoQ8
--HG--
extra : rebase_source : 8a448169c3f47411c705a4d9fd462a1f9363dfd9
extra : amend_source : e6702549527292e2850d16e8f503f0be9848159f
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
Cosmin Sabou
Johann Hofmann
Kartikaya Gupta
Bobby Holley
Noemi Erli
Zhang Junzhi
vinoth
Takuro Ashie
Andrea Marchesini
Jeff Muizelaar
Tiberius Oros
Ryan VanderMeulen
Brindusan Cristian
shindli
Ryan Hunt
Olli Pettay
Andrew Swan
Masayuki Nakano
Benjamin Bouvier
Sebastian Hengst
Daniel Stenberg
Gurzau Raul
Michael Kohler
Nicholas Nethercote
Andreea Pavel
Tristan Bourvon
Catalin Badea
Cameron McCormack
Mathieu Leplatre
Francois Marier
Gijs Kruitbosch
Tom Schuster
Csoregi Natalia
Olli Pettay
Coroiu Cristina
Julian Descottes
Tom Ritter
Nils Ohlmeier [:drno]
Alex Chronopoulos
Christoph Kerschbaumer
Margareta Eliza Balazs
Jonathan Kew
Ting-Yu Lin
arthur.iakab
smswessem
Ciure Andrei
sotaro
Markus Stange
Dan Glastonbury
Xidorn Quan
Boris Zbarsky
Emilio Cobos Álvarez
Jan Odvarko
Valentin Gosu
Liang-Heng Chen
Honza Bambas
Robert Longson
Brian Birtles
Jonathan Kingston
Kris Maglione
Daniel Holbert
Kearwood Gilbert