Merging upstream version 125.0.1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

3 files changed, 5 insertions, 6 deletions

diff --git a/remote/doc/Building.md b/remote/doc/Building.md
index b8ddf5db8d..210510cc14 100644
--- a/remote/doc/Building.md
+++ b/remote/doc/Building.md
@@ -29,7 +29,7 @@ do this, provided you haven’t touched any compiled code (C++ or Rust):
 
 Component files include the likes of components.conf,
 RemoteAgent.manifest, moz.build files, and jar.mn.
-All the JS modules (files ending with `.jsm`) are symlinked into
+All the JS modules (files ending with `.sys.mjs`) are symlinked into
 the build and can be changed without rebuilding.
 
 You may also opt out of building all the WebDriver specific components
diff --git a/remote/doc/cdp/Architecture.md b/remote/doc/cdp/Architecture.md
index bda4956f84..ad6e18eadf 100644
--- a/remote/doc/cdp/Architecture.md
+++ b/remote/doc/cdp/Architecture.md
@@ -84,7 +84,7 @@ When a request is made to a target URL, `cdp/targets/Target:handle` is called an
 From a given connection you can know about the other potential targets.
 You typically do that via `Target.setDiscoverTargets()`, which will emit `Target.targetCreated` events providing a target ID.
 You may create a new session for the new target by handing the ID to `Target.attachToTarget()`, which will return a session ID.
-"Target" here is a reference to the CDP Domain implemented in `cdp/domains/parent/Target.jsm`. That is different from `cdp/targets/Target`
+"Target" here is a reference to the CDP Domain implemented in `cdp/domains/parent/Target.sys.mjs`. That is different from `cdp/targets/Target`
 class which is an implementation detail of the Remote Agent.
 
 Then, there is two ways to communicate with the other targets:
diff --git a/remote/doc/marionette/CodeStyle.md b/remote/doc/marionette/CodeStyle.md
index 0658018a46..19c7ff716d 100644
--- a/remote/doc/marionette/CodeStyle.md
+++ b/remote/doc/marionette/CodeStyle.md
@@ -21,15 +21,14 @@ Marionette is written in JavaScript and ships
 as part of Firefox.  We have access to all the latest ECMAScript
 features currently in development, usually before it ships in the
 wild and we try to make use of new features when appropriate,
-especially when they move us off legacy internal replacements
-(such as Promise.jsm and Task.jsm).
+especially when they move us off legacy internal replacements.
 
 One of the peculiarities of working on JavaScript code that ships as
 part of a runtime platform is, that unlike in a regular web document,
 we share a single global state with the rest of Firefox.  This means
 we have to be responsible and not leak resources unnecessarily.
 
-JS code in Gecko is organised into _modules_ carrying _.js_ or _.jsm_
+JS code in Gecko is organised into _modules_ carrying _.js_ or _.sys.mjs_
 file extensions.  Depending on the area of Gecko you’re working on,
 you may find they have different techniques for exporting symbols,
 varying indentation and code style, as well as varying linting
@@ -178,7 +177,7 @@ The practical details of working on the Marionette code is outlined
 in [Contributing.md], but generally you do not have to re-build
 Firefox when changing code.  Any change to remote/marionette/*.js
 will be picked up on restarting Firefox.  The only notable exception
-is remote/components/Marionette.jsm, which does require
+is remote/components/Marionette.sys.mjs, which does require
 a re-build.
 
 [strict mode]: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode