Add some properties to the migration wizard screen JSON to specify what
action to perform when CTAs inside the embedded migration wizard are
clicked. This lets us advance screens when the cancel or finish button
is clicked, and send telemetry when the start button is clicked. In
theory we could perform any special message actions too, but for now we
only need telemetry and screen navigation.
Differential Revision: https://phabricator.services.mozilla.com/D176358
This patch restores link underlines in the new tab page, particularly the settings page and discovery stream (top sites, pocket tiles, and recent activity). Only links that had underlines on hover were updated. `text-decoration: none` is added for cards to maintain original styling.
Differential Revision: https://phabricator.services.mozilla.com/D176819
Significant portions of this were written by Shane Hughes <shughes@mozilla.com> -
specifically the parts that move the Firefox Account sign-in flow for tabs into
a SpecialMessageAction, and making AboutWelcomeUtils.handleUserAction return
a Promise.
Differential Revision: https://phabricator.services.mozilla.com/D176453
Significant portions of this were written by Shane Hughes <shughes@mozilla.com> -
specifically the parts that move the Firefox Account sign-in flow for tabs into
a SpecialMessageAction, and making AboutWelcomeUtils.handleUserAction return
a Promise.
Differential Revision: https://phabricator.services.mozilla.com/D176453
about:welcome checkboxes can now set an `checkedAction` and an
`uncheckedAction`, which will occur when the checkbox is checked or unchecked,
respectively, and the primary button is clicked.
The old `action` parameter is still supported for backwards compatability, but
`checkedAction` takes precedence.
Differential Revision: https://phabricator.services.mozilla.com/D174192
This adds a card to the about:welcome defaults that embeds the new Migration Wizard
if browser.migrate.content-modal.about-welcome-behavior is set to "embedded".
This requires adding a useEmbeddedMigrationWizard targeting attribute to
ASRouterTargeting.
Differential Revision: https://phabricator.services.mozilla.com/D175945
This commit:
* Adds a `position` key to the `topsites.{impression, click}` events.
This position is zero-based, to align with `pocket_position`.
* Refactors the impression stats actions in `TelemetryFeed` to receive
the zero-based tile position, and adds one to the structured
ingestion payloads and scalar values.
* Adds a new Glean metric, `topsites.rows`, to record the number of
rows shown on the New Tab page.
Differential Revision: https://phabricator.services.mozilla.com/D172292
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
