Update references from JSMs to ES Modules (#652)

This patch updates all our remaining links to JSMs in SearchFox and code
samples to use the new ESMs (.sys.mjs). It also updates some links
inside aboutwelcome/newtab/asrouter that have changed since the
components were refactored. Additionally, the links to Firefox Source
Docs for newtab/asrouter pages have been updated.

docs/deep-dives/desktop/desktop-targeting-debug.md

@@ -29,7 +29,7 @@ Inside the textarea targeting expressions can be written and evaluated using the
 
 ## Builtin functions and examples
 
-The full list of available functions can be seen in [FilterExpressions.jsm](https://searchfox.org/mozilla-central/source/toolkit/components/utils/FilterExpressions.jsm).
+The full list of available functions can be seen in [FilterExpressions.sys.mjs](https://searchfox.org/mozilla-central/source/toolkit/components/utils/FilterExpressions.sys.mjs).
 
 A JEXL function is called using the `|` operator followed by the function name, example: `[1,2,3]|length == 3`.
 

docs/getting-started/engineers/desktop-feature-api.mdx

@@ -13,7 +13,7 @@ This guide will help you use the Nimbus Feature API in Desktop Firefox to run ex
 
 ### Can I use this?
 
-For the JS implementation you can import `ExperimentAPI.jsm` in the parent process or a privileged child process. We _do_ support First run experiments on Windows, holdbacks, and rollouts.
+For the JS implementation you can import `ExperimentAPI.sys.mjs` in the parent process or a privileged child process. We _do_ support First run experiments on Windows, holdbacks, and rollouts.
 
 For the C++ implementation you can import `#include "mozilla/browser/NimbusFeatures.h"` and we support early startup experiments and holdbacks.
 
@@ -105,8 +105,9 @@ Import the `NimbusFeatures` module:
 <TabItem value="js">
 
 ```js
-XPCOMUtils.defineLazyModuleGetters(this, {
-  NimbusFeatures: "resource://nimbus/ExperimentAPI.jsm",
+const lazy = {}
+ChromeUtils.defineESModuleGetters(lazy, {
+  NimbusFeatures: "resource://nimbus/ExperimentAPI.sys.mjs",
 });
 ```
 
@@ -344,11 +345,12 @@ NimbusFeatures::OffUpdate("aboutwelcome"_ns, "skipFocus"_ns,
 If you need to know whether an experiment is active or get access to the experiment or branch identifier (for example, to report in `utm_params`), you can use `ExperimentAPI.getExperimentMetaData`:
 
 ```js
-XPCOMUtils.defineLazyModuleGetters(this, {
-  ExperimentAPI: "resource://nimbus/ExperimentAPI.jsm",
+const lazy = {}
+ChromeUtils.defineESModuleGetters(lazy, {
+  NimbusFeatures: "resource://nimbus/ExperimentAPI.sys.mjs",
 });
 
-const data = ExperimentAPI.getExperimentMetaData({ featureId: "myFeature" });
+const data = lazy.ExperimentAPI.getExperimentMetaData({ featureId: "myFeature" });
 
 // If there is no experiment, data will be null.
 const slug = data?.slug;

docs/getting-started/engineers/desktop-migration-guide.md

@@ -9,8 +9,8 @@ This guide will help you migrate your Desktop front-end code to run experiments
 
 Prerequisites:
 * Your experimental variables are already instrumented with Firefox preferences
-* You don't use the `user branch` of each pref for anything other than actual user-defined values or testing (see docs on [order of precedence](/desktop-feature-api#configuration-sources)
-* Your code can import a `jsm`
+* You don't use the `user branch` of each pref for anything other than actual user-defined values or testing (see docs on [order of precedence](/desktop-feature-api#configuration-sources))
+* Your code can import a ESM
 
 ### An illustrative example (about:myself)
 
@@ -48,15 +48,16 @@ aboutmyself:
 
 ## Step 2: Update your feature code
 
-First, you will need to import `ExperimentAPI.jsm`:
+First, you will need to import `ExperimentAPI.sys.mjs`:
 
 ```js
-XPCOMUtils.defineLazyModuleGetters(this, {
-  NimbusFeatures: "resource://nimbus/ExperimentAPI.jsm",
+const lazy = {}
+ChromeUtils.defineESModuleGetters(lazy, {
+  NimbusFeatures: "resource://nimbus/ExperimentAPI.sys.mjs",
 });
 ```
 
-Then anywhere in your code that uses `Services.prefs` to get experiment-defined values, use `NimbusFeatures` instead:
+Then anywhere in your code that uses `Services.prefs` to get experiment-defined values, use `lazy.NimbusFeatures` instead:
 
 ```js
 element.style.backgroundColor = Services.prefs.getBoolPref("browser.aboutmyself.bgColor");

docs/glossary.mdx

@@ -1,10 +1,10 @@
 ---
-id: glossary 
+id: glossary
 title: Glossary
 slug: /glossary
 ---
 
-## A 
+## A
 
 ----
 
@@ -16,61 +16,61 @@ slug: /glossary
 
 ----
 
-## C 
+## C
 
 **Cirrus**: The codename of Nimbus for Web applications. [PRD](https://docs.google.com/document/d/1bg7GUoGeGusiSHE945P0XWkX_beGDQCb7gTMImliI44/edit#heading=h.hs9kv3uaq67s) and [ADR](https://docs.google.com/document/d/1ub46GXVz0rD6vsdS85UF_LvUfJItMwE9jicFCXc1jvw/edit)
 
 **Co-enrolling**: [here](/fml/coenrolling-features)
 
 **Custom targeting**: coming soon
-   * [Targeting attributes](https://firefox-source-docs.mozilla.org/browser/components/newtab/content-src/asrouter/docs/targeting-attributes.html)
+   * [Targeting attributes](https://firefox-source-docs.mozilla.org/browser/components/asrouter/docs/targeting-attributes.html)
    * [Mobile messaging behavioral targeting](/mobile-behavioral-targeting)
    * See also: "Targeting Considerations" on the Nimbus Experiment Brief template available [here](/for-product#where-do-i-start)
 
 ----
 
-## E 
+## E
 
-**Experimenter**: 
+**Experimenter**:
 <ul>
-Nimbus is the whole experimentation system (handles enrolling/unenrolling users, sending branch configurations, etc). Nimbus was the code name of the experimentation project. 
+Nimbus is the whole experimentation system (handles enrolling/unenrolling users, sending branch configurations, etc). Nimbus was the code name of the experimentation project.
 </ul>
 <ul>
 Experimenter is the customer interface to both Nimbus and Jetstream - that you access at <a href="https://experimenter.services.mozilla.com/">experimenter.services.mozilla.com/</a>. In Experimenter users can configure experiments, manage them (launch, monitor, end), and can see the results.
 </ul>
 
 ----
 
-## F 
+## F
 
 **First-run experiment**: [here](/mobile-first-run-experiments)
 
 **Feature Manifest Language (FML)**: [here](/fml-spec)
 
 ----
 
-## J 
+## J
 
-**Jetstream**: 
+**Jetstream**:
 <ul>
 Jetstream is the whole analysis system (interfaces with data, runs analysis, formats results). See more <a href="/deep-dives/jetstream/overview">here</a>
 </ul>
 
 ----
 
-## K 
+## K
 
 **Kinto**: [docs](https://docs.kinto-storage.org/en/stable/index.html)
 
 ----
 
-## R 
+## R
 
-**Remote Settings**: 
+**Remote Settings**:
    * [Docs](https://remote-settings.readthedocs.io/en/latest/)
    * [Integration with Experimenter](https://github.com/mozilla/experimenter/tree/main/docs/experimenter#overview)
 
-**Rollout**: 
+**Rollout**:
 <ul>
 A single-branch experiment, often the "winning branch" from an experiment, that can be used to "roll out" a feature to your Audience. See the <a href="/deep-dives/experimenter/rollouts">Rollouts deep dive</a> for more info.
 </ul>
@@ -80,8 +80,8 @@ A single-branch experiment, often the "winning branch" from an experiment, that
 ## S
 
 **Smoke Test**:
-<ul> 
-A smoke test is a preliminary trial/experiment with minimal setup/limited parameters/minimal user population to ensure that the experiment is operational and that there are no obvious issues. The objective is to catch any major problems early on, allowing us to address them before conducting more in-depth/resource-intensive (stat.sig) experiments.  This is common when there are new pieces (like many newly added telemetry probes or complex targeting or triggers) coming together.  It is better to learn in a small (hundreds instead of hundreds of thousands people) experiment that your message is triggering at the wrong time to the wrong users, or that your telemetry isn't capturing something you need to learn. 
+<ul>
+A smoke test is a preliminary trial/experiment with minimal setup/limited parameters/minimal user population to ensure that the experiment is operational and that there are no obvious issues. The objective is to catch any major problems early on, allowing us to address them before conducting more in-depth/resource-intensive (stat.sig) experiments.  This is common when there are new pieces (like many newly added telemetry probes or complex targeting or triggers) coming together.  It is better to learn in a small (hundreds instead of hundreds of thousands people) experiment that your message is triggering at the wrong time to the wrong users, or that your telemetry isn't capturing something you need to learn.
 </ul>
 
 ----

docs/workflow/implementing/messaging/desktop-messaging-journey.md

@@ -9,7 +9,7 @@ From inception to launch, a message goes through the below three steps for Firef
 
 ## Message Design
 
-Once an idea has been developed, the next step is designing the experiment message. A good place to start for some inspiration, is to look through previous messaging system experiments (Examples in Source doc) as well as looking into the available capabilities through the  [Messaging Surfaces](/messaging/desktop-messaging-surfaces). The OMC team has vast experience with running these experiments and can provide feedback and answer any questions in the #omc Slack channel. 
+Once an idea has been developed, the next step is designing the experiment message. A good place to start for some inspiration, is to look through previous messaging system experiments (Examples in Source doc) as well as looking into the available capabilities through the  [Messaging Surfaces](/messaging/desktop-messaging-surfaces). The OMC team has vast experience with running these experiments and can provide feedback and answer any questions in the #omc Slack channel.
 
 ## Running an Experiment
 
@@ -20,12 +20,12 @@ For a more in-depth guide and step by step process, visit [OMC: Experimenter onb
 
 Once the experiment has successfully concluded and analysis shows promising results, we can land the new message in tree. Depending on the messaging surface, the following files is where the JSON for our different messages exists
 
-```
-browser/components/newtab/aboutwelcome/lib/AboutWelcomeDefaults.jsm
-browser/components/newtab/lib/FeatureCalloutMessages.jsm
-browser/components/newtab/lib/OnboardingMessageProvider.jsm
-```
-
-Visit [Firefox Source docs](https://firefox-source-docs.mozilla.org/browser/components/newtab/docs/index.html): newtab for details on how to develop within our components.
+* [`browser/components/aboutwelcome/modules/AboutWelcomeDefaults.sys.mjs`][AboutWelcomeDefaults]
+* [`browser/components/asrouter/modules/FeatureCalloutMessages.sys.mjs`][FeatureCalloutMessages]
+* [`browser/components/asrouter/modules/OnboardingMessageProvider.sys.mjs`][OnboardingMessageProvider]
 
+Visit [Firefox Source docs](https://firefox-source-docs.mozilla.org/browser/components/newtab/docs/index.html): newtab for details on how to develop within our components.
 
+[AboutWelcomeDefaults]: https://searchfox.org/mozilla-central/source/browser/components/aboutwelcome/modules/AboutWelcomeDefaults.sys.mjs
+[FeatureCalloutMessages]: https://searchfox.org/mozilla-central/source/browser/components/asrouter/modules/FeatureCalloutMessages.sys.mjs
+[OnboardingMessageProvider]: https://searchfox.org/mozilla-central/source/browser/components/asrouter/modules/OnboardingMessageProvider.sys.mjs

docs/workflow/implementing/messaging/display-logic.md

@@ -30,7 +30,7 @@ Sometimes you want to limit messages to a particular group of users, to users wi
 
 > All users in the `US`, for `beta and nightly channels`, `version 98.01 or higher`, who `do not have Firefox set to their default browser`.
 
-You can see a complete [list of the available attributes](https://firefox-source-docs.mozilla.org/browser/components/asrouter/docs/targeting-attributes.html#available-attributes) in Firefox Source docs, but here are some common examples:
+You can see a complete [list of the available attributes](https://firefox-source-docs.mozilla.org/browser/components/asrouter/docs/targeting-attributes.html) in Firefox Source docs, but here are some common examples:
 
 * `locale` (language, e.g. `en-CA`)
 * `region` (based on IP, e.g. `US`, `FR`)

docs/workflow/implementing/messaging/how-a-message-gets-shown.md

@@ -12,7 +12,7 @@ All messages belong to a message provider (a source):
 
 All messages have an associated [trigger](/messaging/display-logic/#triggers) (user action targeted by the message) and targeting condition. Additionally messages have a frequency cap and they can belong to a group that also has a frequency cap.
 
-Deciding to show a message [starts with the trigger action](https://searchfox.org/mozilla-central/rev/65d4d3399afa79c8de5a0cc11752d2ba7c31edc1/browser/components/newtab/lib/ASRouter.jsm#1323), when this happens we look at all the messages matching that trigger. We filter out blocked messages or messages that reached their frequency cap (or their groups frequency cap) and we evaluate targeting returning the first message that matched targeting.
+Deciding to show a message [starts with the trigger action](https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/browser/components/asrouter/modules/ASRouter.sys.mjs#1655), when this happens we look at all the messages matching that trigger. We filter out blocked messages or messages that reached their frequency cap (or their groups frequency cap) and we evaluate targeting returning the first message that matched targeting.
 
 This cycle can result in a message being shown (which will send an Exposure event + message specific telemetry events) or no message being shown if targeting didn’t match (but it can still result in a Reach event being sent).
 

docs/workflow/implementing/messaging/telemetry.md

@@ -13,7 +13,7 @@ Event telemetry is sent for any interaction with the messaging surfaces and addi
 
 Telemetry pings will include the message id, experiment and branch slug (if enrolled) and the event type.
 
-Telemetry from all messaging surfaces ([except doorhangers when not enrolled in an experiment](https://searchfox.org/mozilla-central/rev/65d4d3399afa79c8de5a0cc11752d2ba7c31edc1/browser/components/newtab/lib/TelemetryFeed.jsm#645)) includes client id in the event ping. **Special care should be taken not to associate any browsing history with messaging events: showing a message when the user visits a particular website is not allowed because it would accidentally leak information about that visit.**
+Telemetry from all messaging surfaces ([except doorhangers when not enrolled in an experiment](https://searchfox.org/mozilla-central/rev/d1e731d931b7b46237175de1701849a7cf5c8579/browser/components/newtab/lib/TelemetryFeed.sys.mjs#526)) includes client id in the event ping. **Special care should be taken not to associate any browsing history with messaging events: showing a message when the user visits a particular website is not allowed because it would accidentally leak information about that visit.**
 
 [Additional telemetry](/telemetry/) is available when the message is delivered as an <u>experiment</u>:
 - Exposure
@@ -29,6 +29,6 @@ Example: Experiment has 3 branches [control, treatment-1, treatment-2]. If the u
 
 **Debugging telemetry pings**
 
-Make sure `browser.ping-centre.log` pref is enabled. Open the Browser Toolbox and interact with the message, any telemetry pings will be logged to the console. 
+Make sure `browser.ping-centre.log` pref is enabled. Open the Browser Toolbox and interact with the message, any telemetry pings will be logged to the console.
 
 _Because of the implementation of moments pages, telemetry is only sent for when a message is matched (the page will be shown in the next browsing session). No other telemetry is available._