The behavior for non-trusted events matches Safari (Chrome does return
deltaX in that case, which seems pretty bogus, because the sign of the
wheelDelta* is the opposite as the delta* props).
Differential Revision: https://phabricator.services.mozilla.com/D114052
This enables the module that queries OS storage for client certificates when
TLS client authentication is requested by a server. This applies to macOS and
Windows only.
Differential Revision: https://phabricator.services.mozilla.com/D107558
This modification relies on the shared memory implemented in Bug 1698045 and on
the ability to encode and decode self-hosted content from Bug 1668361 to
optimize the JS engine initialization by making the parent process encode the
self-hosted stencil, such that all other runtime initialization would only have
to decode it, including content processes.
Differential Revision: https://phabricator.services.mozilla.com/D110578
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
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
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
This test is for documentation purposes. You may run it locally on Windows by removing the skip-if = true from xpcshell.ini
As sharing folders on windows requires elevated priviledges, you will need to execute some commands in a separate cmd.exe instance with Admin priviledges.
Differential Revision: https://phabricator.services.mozilla.com/D113498
We've been using 3 on Nightly for a long time without
any problems and it's generally much better to keep the GPU
process around than give up on it.
We also bump the Nightly value to increase the chances of us
finding any problems where we should give up on using the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D113393
CLOSED TREE
Backed out changeset 9dea771db2ce (bug 1703934)
Backed out changeset 2a51d2530939 (bug 1703934)
Backed out changeset 6af76624ce86 (bug 1703934)
Fractional scaling currently comes at a high performance cost as we
only support integer scaling for rendering. The overdraw ratio is
something like (ceil(scale) / scale)^2, which for 125% scaling means
we're drawing 2.56 times as much as we should.
In theory we already support everything needed to have proper fractional
scaling: Webrender support appears to be in great shape and on the Wayland
side we can use the wp_viewporter protocol to have arbitrary
buffer size <-> surface size relationships. The main blocker remains the
lack of proper negotiation between client and compositor about the
optimal buffer size.
In order to speed up the upstream discussion, lets implement it via a
fixed value that can be set in `about:config` for testing purposes
(`widget.wayland.fractional_buffer_scale`).
It will, of course, require wp_viewporter support from the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D113321
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This is a bit subtler than needed (ideally we'd just need one pref)
because android enables the support for the type even if it only creates
a textbox.
Co-Authored-By: Fernando García <fernando.garciagomez.01@telefonica.com>
Differential Revision: https://phabricator.services.mozilla.com/D112488
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
This patch turns on Software WebRender for all widgets that don't get
acceleration by default on nightly and early beta, as well as for users
who are put into the Fission experiment. It also cleans up our prefs to
simply enable it for all popups, and not just those affected by Fission.
Differential Revision: https://phabricator.services.mozilla.com/D111958
Safari does this. This reduces the runtime in the example linked from
comment 0 quite a lot (40ms on a local opt build, from ~130ms on a
release nightly build).
I added a pref because there's a slight chance of performance
regressions on pages that do not use attribute selectors, as we're now
doing more unconditional work per element (adding the attributes to the
bloom filter). But the trade-off should be worth it, I think.
Differential Revision: https://phabricator.services.mozilla.com/D111689
Do the minimal amount of work to flip the default sense of the pref from false
to true.
One test case had to be tweaked because it assumed a 2GB max and we had not
stressed this with the --large-arraybuffer switch.
Added a test for the --no-large-arraybuffer switch.
Various test cases had to be tweaked to use the largeArrayBufferEnabled
predicate to guard tests that assumed specific buffer sizes, when those tests
could not easily be updated.
Differential Revision: https://phabricator.services.mozilla.com/D111100
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
Loading cached shaders with glProgramBinary fails consistently for all
but the most trivial of our shaders on Adreno 3xx, so caching and
attempting to load them is a waste of time. Chromium and other
projects also appear to have disabled their shader caches on Adreno
3xx due to bugs.
This patch moves the gfx.webrender.program-binary-disk pref
declaration from all.js to StaticPrefList.yaml. Rather than directly
using the value of the pref to decide whether to create the shader
cache, we now initialize a Feature in gfxConfigManager with a default
value from the pref and then configure it from the blocklist. On
Android we block the feature on Adreno 3xx devices. The pref remains
true by default on Android and Windows, and false by default on Linux
and Macos.
Differential Revision: https://phabricator.services.mozilla.com/D111427
This commit adds a declarative `JS_FOR_WASM_FEATURES` macro which
expands for every WebAssembly proposal we are gating. Most feature
gating code is refactored to use this macro so that we have one place
we need to change to get the majority of this code working. The only
place that needs to be updated for new features is the browser pref
declaration code, as that cannot use this macro. This is documented
in the new WasmFeatures.h header.
The feature gating logic should work almost identically as before.
The changes are:
* All browser prefs are moved to StaticPrefList.yaml
* The code to enable a feature was conditionally compiled to not
enable the feature at variously stages of the "flag-flow". Now
the only place that is conditionally compiled to not work is
in the WasmXFlag functions. This is to make the macro simpler
and might be able to be reverted if need be.
* The flag for gc is shortened from gcTypes to gc so that the
existing usages of the wasmGcEnabled shell function don't have
to change.
This commit also has the effect of giving function-references/gc/
exception-handling a proper browser pref for enabling the features.
Differential Revision: https://phabricator.services.mozilla.com/D110820
For webcompat reasons, we have determined that we should only limit the length
of URIs in specific cases. We're going to handle this on the GV side instead.
Differential Revision: https://phabricator.services.mozilla.com/D109426
Flip javascript.options.wasm_simd to true for beta and release.
This patch leaves the flag as true on nightly and otherwise false, for arm64,
since arm64 code landing is imminent. But in truth simd is not even compiled
in for arm64 at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D111285
The patches on this bug make bug 1684441 increase in frequency. Presumable ASAN
shutdown is in many cases already close to the timeout, and this bug is making
it trip over the edge.
A 4 minute timeout made a broad linux x64 ASAN try run go from five occurrences
of bug 1684441 to two, whereas a 5 minute timeout made them go to zero.
Differential Revision: https://phabricator.services.mozilla.com/D109785
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
This makes the snapback less aggressive, and feels more like Safari to me.
Reducing the stiffness makes the animation take longer to complete.
To counteract the longer time, I've also reduced the damping a little bit;
reducing the damping makes the animation complete a little more quickly.
Depends on D110845
Differential Revision: https://phabricator.services.mozilla.com/D110846
This change constitutes a way we can redirect users to an actual page that
explains what captive portals are and why we are making these requests.
Normally users should not see this page, as we only compare the contents
of a small html file. The meta redirect only happens when loaded in a
page.
The SUMO URL https://support.mozilla.org/kb/captive-portal will automatically
redirect to the appropriate locale.
Differential Revision: https://phabricator.services.mozilla.com/D99773
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
The patches on this bug make bug 1684441 increase in frequency. Presumable ASAN
shutdown is in many cases already close to the timeout, and this bug is making
it trip over the edge.
A 4 minute timeout made a broad linux x64 ASAN try run go from five occurrences
of bug 1684441 to two, whereas a 5 minute timeout made them go to zero.
Differential Revision: https://phabricator.services.mozilla.com/D109785
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
No reason that code needs to be there. The findbar modal highlight stuff is not
being worked on and it was unclear to me why it needed a fission check, so I
removed that special case. The findbar code can customize the colors with
Selection.setColors anyways, which is a better fix.
Depends on D110673
Differential Revision: https://phabricator.services.mozilla.com/D110674
This is a follow-up that I thought was worth doing, but let me know if
you disagree or what not. I think this produces the best results:
* For light pages, we still get light scrollbars for the track, but the
active thumb still uses the dark theme highlight color.
* For dark pages, we again still use the themed highlight color for the
thumb, and we use dark scrollbar colors elsewhere like we do now.
Again, let me know if you think this is not worth it, or is too much, or
what not. I've tested this on a decent range of popular GTK themes and
it looks like a clear progression to me.
Differential Revision: https://phabricator.services.mozilla.com/D110203
Selection and accent color should be uncontroversial, since we ensure
the darker variant goes in the background, and the scrollbars were
intended to get passed from the parent theme in bug 1669368, but it was
regressed by the initial RemoteLookAndFeel work.
Differential Revision: https://phabricator.services.mozilla.com/D110175
This patch adds an expiration tracker to decide when to unmap unused
shared surfaces from our address space to reclaim virtual memory. This
is only used on 32-bit builds of Firefox where there is meaningful
virtual address space pressure.
Differential Revision: https://phabricator.services.mozilla.com/D109440
Andrew Osmond
Emilio Cobos Alvarez
Dana Keeler
Dragana Damjanovic
Nicolas B. Pierron
Paul Bone
Robert Mader
Matt Woodrow
Dorel Luca
Timothy Nikkel
Glenn Watson
Aaron Klotz
Alexandru Michis
Jens Stutte
Valentin Gosu
Kagami Sascha Rosylight
Noemi Erli
Csoregi Natalia
Henri Sivonen
Markus Stange
Ryan Hunt
sanketh
Iulian Moraru
Lars T Hansen
Xidorn Quan
Matthew Gaudet
Butkovits Atila
Olli Pettay
Narcis Beleuzu
Chris Martin
Kershaw Chang
Jan Varga
Jeff Muizelaar
Sean Feng
Brindusan Cristian
Christoph Kerschbaumer
Tom Schuster
Agi Sferro
Chris Fallin
Jon Bauman
Paul Adenot
Mark Striemer
Sarah Ukoha
Botond Ballo
Gijs Kruitbosch
Julian Seward
Edgar Chen
Boris Chiou
Jonathan Kew
Eugen Sawin
Morgan Reschenberg
Jamie Nicol
Mike Conley
Marco Bonardo
Cosmin Sabou
Ryan VanderMeulen
Yulia Startsev
Bernard Igiri
smolnar
Martin Thomson
Andreas Pehrson
David Parks
stransky
Caroline Cullen
Tom Tung