This patch contains a generic implementation of the algorithms in
AudioNodeEngine.cpp, and this generic implementation is instantiated for
SSE2 and NEON. Note that with this approach, supporting AVX would only
require a few lines.
Differential Revision: https://phabricator.services.mozilla.com/D162494
This patch adds a Nimbus feature for the pref-setting experiment. The
Nimbus feature controls the ETP level 2 list pref for the private
browsing mode.
Differential Revision: https://phabricator.services.mozilla.com/D165952
The code for determining this is now shared with that for `contain: size`,
since the specification says that `content-visibility` follows `contain:
size` in determining applicability.
Differential Revision: https://phabricator.services.mozilla.com/D166689
The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.
This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).
This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.
Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D166756
This was useful when debugging the menu tests and so on, but the
condition is not unexpected nor rare and thus shouldn't warn.
(No review, trivial debug-only)
Differential Revision: https://phabricator.services.mozilla.com/D166758
Ideally, this pref wouldn't be exposed to users at all, because if a user
changes the value, it will cause our telemetry to be over or under sampled
for that user. That's a small risk to take since most users don't change
pref values.
Differential Revision: https://phabricator.services.mozilla.com/D160963
The crash was caused by us loading `http://a.b.c.XN--pokxncvks/`
Because we searched for xn-- case sensitively, the first time around
the URL would parse, and would be lowercased, but when deserializing
the nsIPrincipal we would then fail to parse it.
Differential Revision: https://phabricator.services.mozilla.com/D166649
This replaces `Services.locale.appLocaleAsBCP47` with `regionalPrefsLocales[0]`
when determining the temperature unit to use for weather suggestions.
In summary, that means two things:
* When the language of the OS locale is the same as the language of the app's
locale, weather suggestions will use the OS locale. e.g., if your OS locale is
en-CA but your Firefox is en-US, weather will prefer en-CA since both locales
are English, and so temperatures will be shown in C. This is a change from the
current behavior, where they would be shown in F.
* When the user checked the "Use your operating system settings..." checkbox in
about:preferences for unit formatting, weather suggestions will always use the
OS locale, regardless of the app locale.
This is due to how `regionalPrefsLocales` works [1].
This revision also makes a couple of changes to code added in D166216:
* Instead of storing both C and F temperatures in the UrlbarResult payload,
store only the user's appropriate temperature. This allows the xcpshell test
(test_weather.js) to test locale behavior instead of having to do it in a
browser test, and there's no reason not to do it anyway.
* Replace the hardcoded expected suggestion properties in test_weather.js with
the ones from `WEATHER_SUGGESTION`, as was the case before D166216.
[1] `regionalPrefsLocales` is implemented [here](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/intl/locale/LocaleService.cpp#485). If
`intl.regional_prefs.use_os_locales` is true, `regionalPrefsLocales` returns the
user's OS locales. The checkbox for this pref [is visible](https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/browser/components/preferences/main.js#1485-1491) only when the user's
primary OS locale doesn't match the app's primary locale. The full label for the
checkbox is [here](https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/browser/locales/en-US/browser/preferences/preferences.ftl#324). The pref defaults to false.
If `intl.regional_prefs.use_os_locales` is false, `regionalPrefsLocales` returns
the OS locales only if the OS locale's language is the same as the app locale's
language. Otherwise it returns the app's locales.
In either case, if an error is encountered, the app's locales are returned.
Differential Revision: https://phabricator.services.mozilla.com/D166722
Bug 1796518 removed the build-id on local builds because it's faster to
do so, but it may be desirable to still have /some/ build-id, even if
it's random, so use a uuid on local builds instead of none at all.
Differential Revision: https://phabricator.services.mozilla.com/D166615
serge-sans-paille
William Durand
Jan Varga
Jan de Mooij
Gregory Pappas
Dão Gottwald
Tim Huang
Martin Robinson
Edgar Chen
James Teh
Mozilla Releng Treescript
Cristian Tuns
Emilio Cobos Álvarez
Lee Salzman
Mike Hommey
Timothy Nikkel
Norisz Fay
Andrew McCreight
Gijs Kruitbosch
alwu
Brad Werth
Butkovits Atila
Valentin Gosu
Mark Striemer
Drew Willcoxon
Micah Tigley
Kelly Cochrane
Ryan VanderMeulen
Morgan Rae Reschenberg