This I'm not 100% sure. Should be harmless, but it's a bit subtle.
Maybe we should special-case it with "we're at the beginning of the
pattern"? Reasoning below:
The previous patch restores the performance of the original test-case.
However, if you go to the reduced test-case and try to type " re" in the
findbar, we still take a long time. The reason for that is not that the
previous patch is not effective, but that the findbar sends find
requests as soon as you type, and thus we end up with a request to find
" ", which matches a gazillion spaces in the page and causes us to use
tons of memory and time. Finding " re" is actually super-fast :-)
This fixes it, but it is a bit subtle, so thoughts? Perhaps the findbar
should wait a bit to perform the search before sending a query for " "
instead or something? But I'd rather make it fast.
Differential Revision: https://phabricator.services.mozilla.com/D111634
This expands on existing checks when getting a webms buffered intervals. The
additional check ensures we don't end up with end < start due to our code that
clamps end at duration.
This patch moves those checks into their own helper function so as to reduce
clutter in GetBuffered.
Differential Revision: https://phabricator.services.mozilla.com/D111152
This can happen with whitespace, and can cause us to scan whitespace
exponentially. Should be straight-forward and have no behavior change.
This restores the performance characteristics of the findbar before
the regressing bug.
Differential Revision: https://phabricator.services.mozilla.com/D111633
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
We seem to be hitting a surprising amount of allocator contention just allocating
and converting the CString inside CrashAnnotationGuard. This just modifies the
previous patch to cache that conversion so that we never have to do it dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D111537
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
Only the label was changed in bug 1694229, causing issues with the existing access key (still used in <89 for "Stop it").
Changing both IDs to force retranslation.
Differential Revision: https://phabricator.services.mozilla.com/D111576
Use widget.wayland.test-workarounds.enabled pref to apply Wayland focus workaround - hide/show nsWindow.
Delay nsWindow::Show() operation to avoid Gtk merge both operations to one which may result to no-op.
Depends on D111600
Differential Revision: https://phabricator.services.mozilla.com/D111601
In the Proton UI the disabled extension pageActions are not available in both the urlbar
and the urlbar overflow menu, and non or the builtin actions seems to be visible when
disabled in Proton. And so this particular rule isn't needed in Proton and can be moved
into the group of stylesheet rules restricted to the non-Proton UI.
Differential Revision: https://phabricator.services.mozilla.com/D111602
This patch avoids rasterizing huge conic gradient render tasks by setting a max resolution on each axis and passing a scale factor to the shader (simply reducing the resolution and stretching a conic gradient would be incorrect when the scaling isn't the same on the x and y axis).
Differential Revision: https://phabricator.services.mozilla.com/D111134
The timeout expectation got added after the synchronization of
web-platform-tests with the upstream repository in bug 1702830.
Differential Revision: https://phabricator.services.mozilla.com/D111585
We also call setHelperThreadTaskCallback earlier, now it's done in
XPCJSContext::Initialize. So GlobalHelperThreadState could know earlier
if we're dispatching to a external thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D110924
Emilio Cobos Álvarez
Bryce Seager van Dyk
Valentin Gosu
Lars T Hansen
Molly Howell
Jonathan Kew
Tooru Fujisawa
Julian Seward
Marco Bonardo
Falguni Islam
Tom Schuster
Lee Salzman
Edgar Chen
Mark Banner
Jamie Nicol
ffxbld
Harry Twyford
Jan de Mooij
Francesco Lodolo (:flod)
Chris H-C
Geoff Brown
Hubert Boma Manilla
Sarah Ukoha
Gabriele Svelto
Itiel
Sebastian Hengst
Paul Zuehlcke
stransky
Luca Greco
Kershaw Chang
Nicolas Silva
Gabriel Luong
championshuttler
Yoshi Cheng-Hao Huang
Ed Lee