This doesn't happen on any P1 platforms. It affects all non-x86/x86_64
Linuxes though, in this example, aarch64-linux. It causes Valgrind runs on
aarch64-linux to report hundreds of errors. In short, attempts to read
various fields from /proc/cpuinfo fail, because `CollectProcessInfo()` assumes
that it is looking at a /proc/cpuinfo file from a x86_{32,64} target, but its
format is very different on non x86 targets. Unfortunately the parsing fails,
but the failure is not detected, resulting in the uninitialised fields being
treated as if they contained real data.
The simple fix here is just to give default values for these fields.
Differential Revision: https://phabricator.services.mozilla.com/D123189
Traditionally pointer values (tls, heap pointer) were represented as
RegI32 because we "know" that that is really a GPR, even if the GPR is
64-bit on 64-bit systems.
Later, we introduced RegPtr to hold pointer values that were not
reference values, but used only in some cases. Let's use RegPtr to
hold the tls and heapreg pointer values now, introducing better type
safety that will aid us in the memory64 work.
There's a wrinkle because RegPtr can't be stored on the value stack.
Recently a "RegIntptr" abstraction was introduced as part of the
cleanup of WasmBCMemory, but this is not necessary at this time: all
we need is a local conversion to RegI32 or RegI64 as appropriate for
the platform, in the one place where this is needed, to push a RegPtr
value. So simplify this code by removing RegIntptr again and adding
some local conversion functions.
Drive-by fix: Remove some redundant annotations on method definitons.
Differential Revision: https://phabricator.services.mozilla.com/D125060
This API helps knowing why a given JS object it being kept alive.
You also have to manually modify the codebase to tell which precise object instances
you want to trace:
```
// From a DevTools CommonJS module:
const { track } = require("devtools/shared/test-helpers/tracked-objects.jsm");
// From anything else, JSM, XPCOM module,...:
const { track } = ChromeUtils.import("resource://devtools/shared/test-helpers/tracked-objects.jsm");
track(myLeakedObject);
```
Differential Revision: https://phabricator.services.mozilla.com/D123834
Traditionally pointer values (tls, heap pointer) were represented as
RegI32 because we "know" that that is really a GPR, even if the GPR is
64-bit on 64-bit systems.
Later, we introduced RegPtr to hold pointer values that were not
reference values, but used only in some cases. Let's use RegPtr to
hold the tls and heapreg pointer values now, introducing better type
safety that will aid us in the memory64 work.
There's a wrinkle because RegPtr can't be stored on the value stack.
Recently a "RegIntptr" abstraction was introduced as part of the
cleanup of WasmBCMemory, but this is not necessary at this time: all
we need is a local conversion to RegI32 or RegI64 as appropriate for
the platform, in the one place where this is needed, to push a RegPtr
value. So simplify this code by removing RegIntptr again and adding
some local conversion functions.
Drive-by fix: Remove some redundant annotations on method definitons.
Differential Revision: https://phabricator.services.mozilla.com/D125060
Text is the exception, where clipping the WR commands to the paint rect can let us reduce the size sent.
We want to avoid this when doing fallback painting, since we don't want to have to track paint rect changes for invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D124589
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
This seems to match the expectation of ~all our stylesheets, which have
nice things for HCM / forced-colors which only happen when actually
using OS HCM.
Differential Revision: https://phabricator.services.mozilla.com/D125269
This bug was introduced with the Proton tab design. Since we no longer draw a background behind inactive tabs, tabs are not legible against some accent colors. This problem is especially bad in brighttext themes. This patch also fixes 1714507, since the tabs are now legible against the light gray inactive window color.
Differential Revision: https://phabricator.services.mozilla.com/D125213
accent-color is inherited, there's no need to set it on every element.
And since it's ignored in HCM we can just put it in the regular place.
Differential Revision: https://phabricator.services.mozilla.com/D125273
With the non-native theme we don't need filter for this to affect
"native" inputs, we can just implement the logic in nsNativeBasicTheme
instead.
A bit unfortunate that we need that special-case, but it seems better
than using filter, which can break websites due to it creating an
stacking context.
I _think_ there are tests that I need to adjust for this change, but if
not I'll write some.
Keep the current behavior behind a pref just in case.
Differential Revision: https://phabricator.services.mozilla.com/D125232
And this renames the method to `ExtendOrShrinkRangeToDelete` for alining to
new behavior changed by the following patch.
Depends on D125028
Differential Revision: https://phabricator.services.mozilla.com/D125029
Per spec, the informational description about data collection under the main
Firefox Suggest checkbox should be hidden except for the "online" scenario,
since only the online scenario sends data to Mozilla.
We're also changing the two checkbox labels and adding another description under
the sponsored checkbox.
Depends on D125024
Differential Revision: https://phabricator.services.mozilla.com/D125031
Enable the Firefox Suggest "offline" scenario by default for users in the US
region with en-* locales.
Previously we relied on Nimbus to enable the offline scenario, and the goal here
is to make it permanent for all users in the US `home` region using en-* locales
so that we don't need Nimbus for it anymore.
With Nimbus, there were two essential mechanisms that restricted the scenario to
the desired population: the `browser.urlbar.quicksuggest.enabled` pref, which is
a global toggle for Firefox Suggest suggestions regardless of region and locale,
and a Nimbus recipe that enabled the pref for US en-* users only.
Without Nimbus, we have only the `browser.urlbar.quicksuggest.enabled` pref. We
can't rely on a server-side solution to target a specific population, so we need
to do it in the client. This patch keeps the default `false` value of
`browser.urlbar.quicksuggest.enabled` in firefox.js, and then it sets a new
default-branch value for the pref for the US en-* population on app startup.
There's actually a set of prefs related to the offline scenario that need to be
set, not only `browser.urlbar.quicksuggest.enabled`.
Depends on D124943
Differential Revision: https://phabricator.services.mozilla.com/D125024
Julian Seward
Csoregi Natalia
Valentin Gosu
Lars T Hansen
Alexandre Poirot
Cristian Tuns
Victor Porof
Matt Woodrow
Emilio Cobos Álvarez
Harry Twyford
Michelle Goossens
Itiel
Antonin LOUBIERE
Renovate Bot
Sylvestre Ledru
André Bargull
criss
Matthew Gregan
Narcis Beleuzu
Tomislav Jovanovic
Jon Coppeard
Dão Gottwald
Masayuki Nakano
Myk Melez
Drew Willcoxon