We have some settings that we don't handle well if they change
at runtime. Make them mirror:once.
In the case of `wideget.wayland_vsync.enabled`, this was practically
already the case but in a deprecated way. While on it, use the chance to
rename it to `widget.wayland.vsync.enabled` so it matches other
configs.
Differential Revision: https://phabricator.services.mozilla.com/D114664
Originally, we would restart the GPU process a fixed number of attempts
based on the layers.gpu-process.max_restarts pref. With this patch, we
now use this pref to control how many "unstable" restarts we allow. A
restart is "stable" if and only if the process uptime exceeds the pref
layers.gpu-process.stable.min-uptime-ts and if the process renders a
total number of frames exceeding the pref
layers.gpu-process.stable.frame-threshold. This allows users to keep the
GPU process for a lot longer if they are encountering infrequent
crashes. Should the user experience the GPU process crashing quickly
and/or without rendering many frames, we will disable it as before after
a few attempts and move into the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D114531
Because of the way the process priority manager works, a tab switch may alter
priorities like so:
1. User switches from `tab1` to `tab2`;
2. We drop `tab1`'s content process priority;
3. We raise `tab2`'s content process priority;
But if `tab1` and `tab2` live in the same content process, then not only is
the priority adjustment redundant, it gives Android an opportunity to kill
the content process between steps (2) and (3)!
By setting a brief grace period, the priority manager will wait a bit until
dropping priority of `tab1`:
1. User switches from `tab1` to `tab2`;
2. We start the grace period for dropping `tab1`'s priority;
3. We go to raise `tab2`'s priority, but since the content process is already
foreground, this becomes a no-op;
4. Grace period expires for `tab1`, but we see that `tab2` is still using our
content process, so the "drop" becomes a no-op.
Nightly only for now, we'll see how this affects tab kills.
Differential Revision: https://phabricator.services.mozilla.com/D114507
Win32 errors ERROR_DEVICE_HARDWARE_ERROR, ERROR_DEVICE_NOT_CONNECTED, ERROR_DISK_FULL need a mapping.
NS_ERROR_FILE_DISK_FULL is duplicate to NS_ERROR_FILE_NO_DEVICE_SPACE
Drive by: RejectJSPromise lacked some NS_ERROR_* mappings
Differential Revision: https://phabricator.services.mozilla.com/D113974
If a user is able to get D3D11, and Software WebRender hasn't been
forced on (either by the Fission experiment or our pref), then we prefer
D3D11 in late beta and release. This will allow users who start with
D3D11 in the GPU process, to fallback to Software WebRender in the GPU
process.
Differential Revision: https://phabricator.services.mozilla.com/D114286
This can be disabled by setting the following pref to false:
widget.macos.enable-pre-bigsur-workaround-for-dark-mode-context-menus
Differential Revision: https://phabricator.services.mozilla.com/D114037
This commit implements the extended-constants proposal.
* A new feature flag and pref are added.
* Basic tests are added.
Differential Revision: https://phabricator.services.mozilla.com/D112661
Drive-by fix to drop preference for reftypes from StaticPrefList.yaml. This is no
longer used now that the reference types feature gating code is gone.
Depends on D112656
Differential Revision: https://phabricator.services.mozilla.com/D112657
We'll have to pay this startup time penalty eventually for light theme
users as well but, until we do, we can avoid this regression.
Differential Revision: https://phabricator.services.mozilla.com/D114215
Introduce moz.configure, WasmFeatures, and StaticPrefList.yaml
machinery to define a config option for relaxed SIMD
(https://github.com/WebAssembly/relaxed-simd). At the moment, there
are no defined relaxed SIMD opcodes, but a dozen or so are in the
works. This just sets us up for implementing those.
Differential Revision: https://phabricator.services.mozilla.com/D114117
And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
Win32k Lockdown is getting to the point where we *could* have people in the
community start testing. Let's make it easy for them!
Differential Revision: https://phabricator.services.mozilla.com/D108255