This also adds some belt-and-suspenders checks here so that even if the Migration Wizard
somehow gets confused and sends resource types that the migrator can't import from, they'll
just get ignored rather than having a forever-progress-spinner for that resource type.
Differential Revision: https://phabricator.services.mozilla.com/D173848
This bug hits [this path](https://searchfox.org/mozilla-central/rev/3ba3d0a57b6419206f82f80cd6c30faf59397664/browser/components/urlbar/UrlbarView.sys.mjs#549-550) in `#autoOpen`, where it re-uses the current rows as
they exist. Overflow and underflow events aren't fired in that case, so the
`overflow` attribute isn't updated. The bug does not happen when the `else`
branch is hit because `onQueryResults()` clears the rows when the view isn't
open, and after that the rows are rebuilt.
This patch makes us hit the `else` path in this case by storing the width of the
input when the view is closed. If the stored width is different from the current
width, then the overflow state may be incorrect. Taking the `else` branch makes
us go through `onQueryResults()` and clear the rows before opening the view.
This fixes this bug and bug 1759857.
Differential Revision: https://phabricator.services.mozilla.com/D173596
FOG needs to trigger JOG (artifact build support for runtime-defined metrics.
Allows changes and additions to metrics.yamls to be usable from JS without a
compile step) when running an Artifact Build.
So we take `MOZ_ARTIFACT_BUILDS` and pop it into a pref for FOG's use in C++.
Differential Revision: https://phabricator.services.mozilla.com/D173211
We were choosing not to read from the cache if the user has configured the browser
to restore the last session, but there's also the case where the last session might
be restored regardless - for example, to recover from a parent-process crash, after
an update applies, or if using the browser restart shortcut for developers.
Differential Revision: https://phabricator.services.mozilla.com/D173782
The selection getter is nullable. Not having this check causes
browser_experimental_features_filter.js to fail due to the thrown
exception.
Differential Revision: https://phabricator.services.mozilla.com/D173847
We were choosing not to read from the cache if the user has configured the browser
to restore the last session, but there's also the case where the last session might
be restored regardless - for example, to recover from a parent-process crash, after
an update applies, or if using the browser restart shortcut for developers.
Differential Revision: https://phabricator.services.mozilla.com/D173782
Add logic to apply theme colors to Feature Callout based on where it's
going to show. We can use in-content CSS properties for Firefox View and
other themed system pages, but not for PDF.js, nor for any callouts we
might show in the browser chrome in the future. For the browser chrome
in general, we can use the lightweight theme properties directly, in the
same way the chrome frontend does. But PDF.js is a special case, since
although it exists in the chrome, it's meant to appear like it's in the
PDF.js viewer. And the PDF.js viewer has its own theme totally
independent of everything else. So this dynamically applies themes from
different sources.
This also fixes the bug where the PDF.js color scheme could mismatch the
PDF.js viewer if the browser theme and system color scheme don't match,
e.g. where system color scheme is light but a dark theme is installed,
or vice versa. For PDF.js specifically, we can use the
-moz-content-prefers-color-scheme media query to follow the color scheme
as it exists in the PDF.js viewer page instead of the color scheme in
the chrome window where the Feature Callout actually exists.
It also adds or modifies some colors that were previously missing or
different from the prototype, fixes the illegibility of buttons in HCM
and forced colors mode, and makes some other minor color changes.
Differential Revision: https://phabricator.services.mozilla.com/D173088
Add logic to apply theme colors to Feature Callout based on where it's
going to show. We can use in-content CSS properties for Firefox View and
other themed system pages, but not for PDF.js, nor for any callouts we
might show in the browser chrome in the future. For the browser chrome
in general, we can use the lightweight theme properties directly, in the
same way the chrome frontend does. But PDF.js is a special case, since
although it exists in the chrome, it's meant to appear like it's in the
PDF.js viewer. And the PDF.js viewer has its own theme totally
independent of everything else. So this dynamically applies themes from
different sources.
This also fixes the bug where the PDF.js color scheme could mismatch the
PDF.js viewer if the browser theme and system color scheme don't match,
e.g. where system color scheme is light but a dark theme is installed,
or vice versa. For PDF.js specifically, we can use the
-moz-content-prefers-color-scheme media query to follow the color scheme
as it exists in the PDF.js viewer page instead of the color scheme in
the chrome window where the Feature Callout actually exists.
It also adds or modifies some colors that were previously missing or
different from the prototype, fixes the illegibility of buttons in HCM
and forced colors mode, and makes some other minor color changes.
Differential Revision: https://phabricator.services.mozilla.com/D173088
These preferences are sent via Telemetry through TelemetryEnvironment.
For the FirefoxProfileMigrator, which is used for profile resets, we don't
set these prefs during the migration of those resources. Instead, during
OTHERDATA, we examine the prefs.js of the old profile for the prefs and
attempt to migrate them to a new prefs file in the new profile.
Differential Revision: https://phabricator.services.mozilla.com/D173481