Other platforms are going to need more annotations, so this allows us to
update one line while rolling out the feature, rather than updating a
bunch of test expectations. Also should be clearer.
Let me know if there are better ways to do this.
Differential Revision: https://phabricator.services.mozilla.com/D104102
Other platforms are going to need more annotations, so this allows us to
update one line while rolling out the feature, rather than updating a
bunch of test expectations. Also should be clearer.
Let me know if there are better ways to do this.
Differential Revision: https://phabricator.services.mozilla.com/D104102
This makes it easier to play with different appearances, and it
shouldn't be significantly slower. This was useful for my investigation in
bug 1690494.
Differential Revision: https://phabricator.services.mozilla.com/D103968
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
This shipped in 85, we can remove the feature flag now. Keep
:-moz-focusring as an alias to :focus-visible at parse time.
Differential Revision: https://phabricator.services.mozilla.com/D103752
This shipped in 85, we can remove the feature flag now. Keep
:-moz-focusring as an alias to :focus-visible at parse time.
Differential Revision: https://phabricator.services.mozilla.com/D103752
Our existing batched texture upload logic works with pixel buffer objects which we don't use with ANGLE.
The motivation is to avoid expensive driver overhead from submitting many glTexSubImage2D calls (one for each texture cache item) on low-end Intel Windows configurations.
On Windows+Intel it is much faster to use batched draw calls to copy from staging textures to texture cache than using CopySubResourceRegion (when there is a high number of copies).
Differential Revision: https://phabricator.services.mozilla.com/D103333
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
Once all the remaining patches for test tweaks / fixes have landed, this
patch should be green on try. Couple test annotation changes:
* clip-003.html fails the same way it fails on mac (odd, but couldn't
repro...). I'll try to dig a bit more before calling it a day.
* radiobutton-min-size starts behaving like every other platform.
* Event-dispatch-redispatch and baseline-alignment-and-overflow start
passing.
* Couple minor fuzzy annotations (one was backwards, the other was
missing).
Differential Revision: https://phabricator.services.mozilla.com/D103327
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
CLOSED TREE
Backed out changeset 3c771d45563a (bug 1684040)
Backed out changeset 76e79151d53c (bug 1684040)
Backed out changeset 7a993eb7bfde (bug 1684040)
This patch enables EGL robustness with WebRender. It also tries harder
to get RBAB, favouring KHR+RBAB over EXT-RBAB, as testing with Intel and
NVIDIA Mesa drivers on Ubuntu suggests we can get KHR+RBAB but not
EXT+RBAB. It also adds support for requesting NVIDIA specific resets via
EGL_NV_robustness_video_memory_purge.
Differential Revision: https://phabricator.services.mozilla.com/D102971
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
This allows us to default to skipping the bundled Twemoji Mozilla font when running on Win8.1 or later,
where we can assume Segoe UI Emoji is available.
The new pref here replaces the existing pair of boolean prefs that were only supported on Android,
and is now respected on all platforms. Available settings are:
0 disable use of app-bundled fonts
> 0 enable use of app-bundled fonts
< 0 default (auto): decide at startup, based on the system environment
(The pref is relevant only at startup; changing its value during a session will not make the bundled fonts
appear/disappear dynamically.)
Differential Revision: https://phabricator.services.mozilla.com/D102085
Flips the `javascript.options.use_off_thread_parse_global` pref to false.
In this mode, off-thread JS parsing will parse to Stencil and hand that back
to main-thread to instantiate. This removes the `mergeRealms` operation and
more importantly removes restrictions involving atoms-zone GC. This addresses
intermittent stalls that can previously occured where certain incremental GCs
would disable all off-thread parsing for a short while.
Additionally, this switches the JSBC data format from a legacy format to one
based around the Stencil data structures. As a performance consideration, we
currently continue to use the off-thread parse-global for decode operations.
If the GC prevents us from doing this, we simply instantiate the Stencil on
main-thread like for the parse case. Further performance tuning will allow us
to revisit this again in future.
Note that the privileged ScriptPreloader that runs during process startup
still uses the legacy format at this time.
We also change the defaults of the js-shell which requires updating various
help messages.
Differential Revision: https://phabricator.services.mozilla.com/D91743
This patch:
- adds a new pref for site quota.
- sets 25 MB as the default site qutoa.
- renames LocalStorageManager::GetQuota() to LocalStorageManager::GetOriginQuota().
- adds LocalStorageManager::GetSiteQuota().
- updates LocalStorage quota tests.
Differential Revision: https://phabricator.services.mozilla.com/D101756
This patch:
- adds a new pref for site quota.
- sets 25 MB as the default site qutoa.
- renames LocalStorageManager::GetQuota() to LocalStorageManager::GetOriginQuota().
- adds LocalStorageManager::GetSiteQuota().
- updates LocalStorage quota tests.
Differential Revision: https://phabricator.services.mozilla.com/D101756
Warp doesn't use this and there's a lot of complexity to support recompiling
an IonScript while continuing to use the current one.
It might make sense to add a similar hot tier to Warp at some point, but because
Warp uses trial inlining the implementation would likely be pretty different:
we could invalidate, flag the JitScript as supporting different inlining thresholds,
and go back to Baseline to gather information.
Differential Revision: https://phabricator.services.mozilla.com/D101457
This was set to 30 seconds on Nightly in 2016, but it was never
enabled for release builds, so let's at least make it consistent.
Differential Revision: https://phabricator.services.mozilla.com/D101226
This eliminates all of the thread leaks we had on record, while also increasing
our coverage on the code that's used for testing firefox.
Differential Revision: https://phabricator.services.mozilla.com/D100264
This is a backout of b635c277c9f4 (bug 1675138).
It seems that the CRLite certificate transparency ingestion machinery is
missing certificates it should know about, which means that false positives are
possible, which means that users are seeing revoked certificates where they
shouldn't. This patch sets CRLite back to telemetry-only mode while the
infrastructure gets fixed.
Differential Revision: https://phabricator.services.mozilla.com/D101204
TLS error report sending was disabled by default in bug 1579906. The server
that ingested these reports has been decommissioned as well, so this patch
removes this dead code.
Differential Revision: https://phabricator.services.mozilla.com/D99405
This implements the basic image-set notation without the format()
function (for simplicity).
There's a remaining serialization issue (we should probably skip 1x
resolutions), but that's fine for now, I'll address this in a follow-up
when the feature is testable.
The intention is to do the image selection at computed value time
(keeping a selected index or such), but same, follow-up.
This also fixes an issue where the cors-mode for -moz-image-rect and
cross-fade() was getting ignored when parsing.
Differential Revision: https://phabricator.services.mozilla.com/D100640
Added an option to use ConicGradient API as a preference and removed the
corresponding expected FAILing test, over @ntim's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D100554
The goal of the WebGL Working Group was for failIfMajorPerformanceCaveat
to allow websites to make better choices about which content to serve to
users, ideally via offering a choice to users.
I no longer think that this is useful here, or rather it's only ever
useful in the very narrow case: When a website does indeed have a
fallback ready, and the fallback does actually have better perf.
Today this is only true on some Windows systems that have cpu-emulated
webgl, but gpu-accelerated canvas2d, but this is not most systems.
Simultaneously, we've seen a disappointingly large set of websites break
for users that hit the failIfMajorPerformanceCaveat path.
Since the usefulness of failIfMajorPerformanceCaveat is very limited,
and many sites don't cooperate with us (as the user's User Agent), I
think it's best to disable failIfMajorPerformanceCaveat for the time
being.
Differential Revision: https://phabricator.services.mozilla.com/D100534
And re-enable the RemoteLookAndFeel by default with Gtk.
When the RemoteLookAndFeel is enabled and the non-native theme is not
enabled, we still need to configure the Gtk theme in content processes,
since we're still using Gtk to paint widget backgrounds etc. Without
this, we can end up using LookAndFeel colors from a light theme but
painting widget backgrounds from a dark theme.
Other platforms don't configure themes for content processes
differently, so on those platforms LookAndFeelTheme is an empty struct
and we skip the ConfigureTheme call.
Differential Revision: https://phabricator.services.mozilla.com/D100223
This adds a new LookAndFeel implementation, RemoteLookAndFeel, which can
be used in content processes and is supplied with all of its values by the
parent process.
Co-authored-by: Cameron McCormack <cam@mcc.id.au>
Differential Revision: https://phabricator.services.mozilla.com/D97977
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101