'fromChrome' really meant "force tabs to open in the foreground", so let's
rename it accordingly.
This removes the attempt to document arguments for openUILinkIn.
I'll add documentation back on the end of this stack, for openLinkIn, when
various bits are reorganized anyway.
Differential Revision: https://phabricator.services.mozilla.com/D170384
'fromChrome' really meant "force tabs to open in the foreground", so let's
rename it accordingly.
This removes the attempt to document arguments for openUILinkIn.
I'll add documentation back on the end of this stack, for openLinkIn, when
various bits are reorganized anyway.
Depends on D170210
Differential Revision: https://phabricator.services.mozilla.com/D170384
* Use the new RELOAD_BROWSER action to reload the page after the
user chooses to enable cookie banner handling via the CFR onboarding
doorhanger. This allows the user to see the cookie banner disappear
after enabling the feature.
* Also change the doorhanger configuration to make the onboarding
doorhanger persist until the user interacts with it.
Differential Revision: https://phabricator.services.mozilla.com/D168822
Adds new "dismiss" about:welcome action that can be used to close Spotlight modals, sending a DISMISS telemetry ping.
This will allow us to configure buttons permitting a user to exit a multistage Spotlight modal on any screen (currently we can only do this for the last screen and for single screen messages).
Depends on D165254
Differential Revision: https://phabricator.services.mozilla.com/D165981
Unify the values of "source" and "page" as used in FeatureCallout.sys.mjs:
- Explicitly pass in a value for "page" when instantiating a Feature Callout and use this for the value of "page" when sending Feature Callout telemetry and as the "source" when making calls to `sendTriggerMessage`. This avoids the risk of including non-about: page URLs or PDF file extensions in our telemetry.
- Set the value of "page" in an HTML data attribute that can be accessed for use in about:welcome telemetry for Spotlight and Feature Callouts.
- Update references to the page value previously used as the page/source for telemetry from `about:firefoxview` Feature Callouts from "firefoxview" to "about:firefoxview"
- Pass the token "chrome" when creating a callout from the browser chrome and update references to the source in PDF.js messages' targeting
- Update the page value expected in automated tests as needed
Differential Revision: https://phabricator.services.mozilla.com/D165910
This commit trades away consistency in order to reduce code execution.
Hopefully this avoids executing code that is likely not "shutdown
safe" and is inadvertently restarting services or otherwise hanging
when run during shutdown.
The trade off is that the written targeting snapshot may now be
incomplete (which was always the case in the face of runtime errors,
e.g., corrupt a database) or internally inconsistent (which is
probably new). For example, weekly usage could be populated but most
frecent sites could be empty, contradicting the usage. This trade-off
is accepted: occassionally targeting the user "in the
past" (generally, with data captured 30 minutes ago) is preferable to
relatively frequent shutdown crashes.
I would have liked to have checked for `shuttingDown` in
[CachedTargetingGetter](https://searchfox.org/mozilla-central/rev/abf6758ed833c203f84703aa2e3e3d317571b1e9/browser/components/newtab/lib/ASRouterTargeting.jsm#152),
but doing so might throw exceptions (or inject `null` values) where
they were not anticipated, which carries risks that I couldn't easily
mitigate.
If the measure implemented here is ineffective, we'll likely need to
restrict the set of targeting data collected, but I hope to avoid
that, since it reduces the flexibility of the background messaging
targeting significantly, and we may want the agility provided by rich
targeting at an unknown time in the future.
Differential Revision: https://phabricator.services.mozilla.com/D165916
