- 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
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
This patch doesn't change the functionality, it just splits out the code into
separate functions that are easier to read.
MozReview-Commit-ID: Gx05YCxGgve
--HG--
extra : rebase_source : 3b7250cea630bebf35992bb69e651509c863c1c6
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
This retains support for installing unpacked dictionaries, since Hunspell only
supports loading dictionaries from ordinary filesystem paths.
Unpacked extensions are no longer supported on production, except during
development. WebExtensions have no support for the unpacked flag at all, and
specially signed legacy extensions are forbidden from using it, so there's no
point in maintaining support for this install code. Or, more importantly, for
running a nearly complete duplicated set of tests in order to exercise it.
MozReview-Commit-ID: 1fKVgSelJQ8
--HG--
extra : rebase_source : a2e9086a3d050b66eab9c17fff9c2f7189911832
extra : amend_source : da8f6425ec74a824a3d19f13bb4eb51980cd64c1
Early AAAA responses might cause issues on hosts without working native
IPv6 connectivity, of course especially notable in TRR-only mode.
MozReview-Commit-ID: 6ZqE6AKnucH
--HG--
extra : rebase_source : ff42cb8daf941a3fa1f7e783c76d823e879024c3
Sticky prefs are already specifiable with `sticky_pref`, but this is a more
general attribute mechanism. The ability to specify a locked pref in the data
file is new.
The patch also adds nsIPrefService.readDefaultPrefsFromFile, to match the
existing nsIPrefService.readUserPrefsFromFile method, and converts a number of
the existing tests to use it.
MozReview-Commit-ID: 9LLMBJVZfg7
--HG--
extra : rebase_source : fa25bad87c4d9fcba6dc13cd2cc04ea6a2354f51
It optimizes Preferences::IsLocked(), but that function is called fewer than
200 times while starting the browser and opening a range of tabs.
MozReview-Commit-ID: 5q0zS8TSwdu
--HG--
extra : rebase_source : 015c5ebbe28097ef3f02b1062e650df67721f1c3
We have stopped dispatching "keypress" events for non-printable keys
and key combinations for conforming to UI Events and following the
other browsers.
However, this change hits a serious bugs of Google Docs, Google
Spreadsheets and Gmail. Until they will fix their bugs, we should
take back the traditional behavior for keeping Nightly usable for
any Nightly testers.
MozReview-Commit-ID: 9CyEbsFit1S
--HG--
extra : rebase_source : 837288b1fb53121badff4e65094a87cebfe3cfee
I also removed the explanation string in cases where I felt it was obvious.
MozReview-Commit-ID: IyHswX3s23y
--HG--
extra : rebase_source : ee0a4729b486e42bd50edf3d5870368e0aaa2310
The following table shows the effect of this change:
> old 64-bit new 64-bit old 32-bit new 32-bit
> sizeof(CallbackNode) 40 32 20 16
> size when heap allocated 48 32 32 16
This reduces memory usage by about 15--40 KB per process.
MozReview-Commit-ID: 4gXgGI3SiJz
--HG--
extra : rebase_source : d62e0b708024b1d8ececd1d5c295159e751e6727
This isn't compelling on its own, but it's necessary for the next patch.
MozReview-Commit-ID: CFON8DCdGoA
--HG--
extra : rebase_source : 2b219e2a1330923f63af6dae1d8ab5f2428f926f
This shows that the objects themselves are accounting for about 60% of the
callback memory on 64-bit, and the domains are about 40%.
MozReview-Commit-ID: JndlyIvlrGs
--HG--
extra : rebase_source : 7a60203421c3e03d7cbe36614c72ffe674a4bc71
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : e455f934e6e6d65d54c122a6cec9f6cabbd5ac78
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 and early Beta.
MozReview-Commit-ID: 5IIL9huejXH
--HG--
extra : rebase_source : 0abdbe84a50d6fd1b4d52521b92e7513483b197c
image.animated.decode-on-demand.threshold-kb is the maximum size in kB
that the aggregate frames of an animation can use before it starts to
discard already displayed frames, and redecode them as necessary. The
lower it is set to, the less overall memory we will consume at the
expense of execution time for as long as the tab with the animation(s)
above the threshold are kept open.
image.animated.decode-on-demand.batch-size is the minimum number of
frames we want to have buffered ahead of an animation's currently
displayed frame. The decoding will request this number of frames at a
time to maximize use of memory caching. Note that this is related to the
above preference as well; increasing the batch size will in effect raise
what the minimum threshold. This simplifies the logic in patches later
in the series.
For FF59, we disabled WebVR for macOS before allowing it to ride the trains to release. Softvision was unable to verify for QA due to challenges getting a working hardware configuration for macOS VR at SoftVision.
We have since gained approval from the Firefox Release Team to re-enable WebVR for macOS in release for FF60.
Essentially, we need to reverse the changes in bug 1426500 and uplift to FF59/Beta before the next cycle.
--HG--
extra : rebase_source : 1b0c68b130f869f0e71cf2d93db92bb78dddc79b
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
arthur.iakab
Kearwood Gilbert
Masayuki Nakano
Andrew Osmond
Andreea Pavel
Narcis Beleuzu
Emilio Cobos Álvarez
Daniel Holbert
Andrew Swan
Nicholas Nethercote
Kartikaya Gupta
Jan de Mooij
Kris Maglione
Noemi Erli
Bogdan Tara
Jan Beich
Jan Odvarko
Nicolas B. Pierron
Daniel Stenberg
Tom Ritter
Catalin Badea
Dorel Luca
Sebastian Hengst
Bob Owen
Florian Quèze
Jonathan Kingston