Adding upstream version 127.0.upstream/127.0

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

17 files changed, 207 insertions, 37 deletions

diff --git a/docs/code-quality/lint/create.rst b/docs/code-quality/lint/create.rst
index 4da59b83a0..f3afe59ab5 100644
--- a/docs/code-quality/lint/create.rst
+++ b/docs/code-quality/lint/create.rst
@@ -347,7 +347,7 @@ Adding the linter to the CI
 
 First, the job will have to be declared in Taskcluster.
 
-This should be done in the `mozlint Taskcluster configuration <https://searchfox.org/mozilla-central/source/taskcluster/ci/source-test/mozlint.yml>`_.
+This should be done in the `mozlint Taskcluster configuration <https://searchfox.org/mozilla-central/source/taskcluster/kinds/source-test/mozlint.yml>`_.
 You will need to define a symbol, how it is executed and on what kind of change.
 
 For example, for ruff, the configuration is the following:
diff --git a/docs/code-quality/lint/linters/condprof-addons.rst b/docs/code-quality/lint/linters/condprof-addons.rst
index c302eef5be..ca9c869d09 100644
--- a/docs/code-quality/lint/linters/condprof-addons.rst
+++ b/docs/code-quality/lint/linters/condprof-addons.rst
@@ -5,7 +5,7 @@ CondProf Addons is a linter for condprof customization JSON files (see :searchfo
 it reports linting errors if:
 
 - any of the addons required by the customization files (e.g. see :searchfox:`testing/condprofile/condprof/customization/webext.json`)
-  is not found in the tar file fetched through the `firefox-addons` fetch task (see :searchfox:`taskcluster/ci/fetch/browsertime.yml`)
+  is not found in the tar file fetched through the `firefox-addons` fetch task (see :searchfox:`taskcluster/kinds/fetch/browsertime.yml`)
 - or the expected `firefox-addons` fetch task has not been found
 
 Run Locally
@@ -37,7 +37,7 @@ XPI file is missing from the firefox-addons.tar archive
 
 This linting errors is expected to be reported if the linter detected that a confprof customization file
 requires an addon but the related xpi filename is not included in the firefox-addons.tar file fetched
-through the `firefox-addons` fetch task (see :searchfox:`taskcluster/ci/fetch/browsertime.yml`).
+through the `firefox-addons` fetch task (see :searchfox:`taskcluster/kinds/fetch/browsertime.yml`).
 
 If the patch or phabricator revision is not meant to be landed, but only used as a temporary patch
 pushed on try or only applied locally (e.g. to run the tp6/tp6m webextensions perftests with a given
@@ -50,14 +50,14 @@ the linting error have to be fixed before or along landing the change, either by
 - removing the addition to the customization file if it wasn't intended to include that addon to all runs
   of the tp6/tp6m webextensions perftests
 
-- updating the `firefox-addons` fetch task as defined in :searchfox:`taskcluster/ci/fetch/browsertime.yml`
+- updating the `firefox-addons` fetch task as defined in :searchfox:`taskcluster/kinds/fetch/browsertime.yml`
   by creating a pull request in the github repository where the asset is stored, and ask a review from
   a peer of the `#webextensions-reviewer` and `#perftests-reviewers` review groups.
 
 firefox-addons taskcluster config 'add-prefix' attribute should be set to 'firefox-addons/'
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If this linting error is hit, then the `firefox-addons` task defined in :searchfox:`taskcluster/ci/fetch/browsertime.yml`
+If this linting error is hit, then the `firefox-addons` task defined in :searchfox:`taskcluster/kinds/fetch/browsertime.yml`
 is missing the `add-prefix` attribute or its value is not set to the expected 'firefox-addons/' subdir name.
 
 This is enforced as a linting rule because when the condprof utility is going to build a conditioned profile
@@ -69,7 +69,7 @@ names are already available in `$MOZ_FETCHES_DIR/firefox-addons`.
 firefox-addons taskcluser fetch config section not found
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-This linting error is hit if the linter does not find the expected `firefox-addons` task defined in :searchfox:`taskcluster/ci/fetch/browsertime.yml`
+This linting error is hit if the linter does not find the expected `firefox-addons` task defined in :searchfox:`taskcluster/kinds/fetch/browsertime.yml`
 or it is missing the expected `fetch` attribute.
 
 Configuration
diff --git a/docs/code-quality/lint/linters/perfdocs.rst b/docs/code-quality/lint/linters/perfdocs.rst
index 1ec2e33e68..9a5c6f1d2d 100644
--- a/docs/code-quality/lint/linters/perfdocs.rst
+++ b/docs/code-quality/lint/linters/perfdocs.rst
@@ -14,21 +14,42 @@ The mozlint integration of PerfDocs can be run using mach:
 
     $ mach lint --linter perfdocs .
 
+Documentation can be regenerated for performance tests by including the ``--fix`` flag:
+
+.. parsed-literal::
+
+    $ mach lint --linter perfdocs . --fix
+
 
 Configuration
 -------------
 
-There are no configuration options available for this linter. It scans the full source tree under ``testing``, looking for folders named ``perfdocs`` and then validates their content. This has only been implemented for Raptor so far, but Talos will be added in the future. We also hope to expand this to search outside the ``testing`` directory.
+There are no configuration options available for this linter. It scans the full source tree under ``testing``, looking for folders named ``perfdocs``, validates their content, and regenerates the documentation (if ``--fix`` is provided). This has been implemented for all performance testing harnesses, and the documentation generated gets displayed in :ref:`Performance Testing`.
 
-The ``perfdocs`` folders, there needs to be an ``index.rst`` file and it needs to contain the string ``{documentation}`` in some location in the file which is where the test documentation will be placed. The folders must also have a ``config.yml`` file following this schema:
+In the ``perfdocs`` folders, there needs to be an ``index.rst`` file and it needs to contain the string ``{documentation}`` in some location in the file which is where the test documentation will be placed. The folders must also have a ``config.yml`` file following this schema:
 
 .. code-block:: python
 
     CONFIG_SCHEMA = {
+        "definitions": {
+            "metrics_schema": {
+                "metric_name": {
+                    "type": "object",
+                    "properties": {
+                        "aliases": {"type": "array", "items": {"type": "string"}},
+                        "description": {"type": "string"},
+                        "matcher": {"type": "string"},
+                    },
+                    "required": ["description", "aliases"],
+                },
+            },
+        },
         "type": "object",
         "properties": {
             "name": {"type": "string"},
             "manifest": {"type": "string"},
+            "static-only": {"type": "boolean"},
+            "metrics": {"$ref": "#/definitions/metrics_schema"},
             "suites": {
                 "type": "object",
                 "properties": {
@@ -39,22 +60,17 @@ The ``perfdocs`` folders, there needs to be an ``index.rst`` file and it needs t
                                 "type": "object",
                                 "properties": {
                                     "test_name": {"type": "string"},
-                                }
+                                },
                             },
                             "description": {"type": "string"},
+                            "owner": {"type": "string"},
                         },
-                        "required": [
-                            "description"
-                        ]
+                        "required": ["description"],
                     }
-                }
-            }
+                },
+            },
         },
-        "required": [
-            "name",
-            "manifest",
-            "suites"
-        ]
+        "required": ["name", "manifest", "static-only", "suites"],
     }
 
 Here is an example of a configuration file for the Raptor framework:
@@ -75,6 +91,35 @@ Here is an example of a configuration file for the Raptor framework:
             tests:
                 wasm: "All wasm tests."
 
+Metrics that produce alerts can also be documented like so:
+
+.. parsed-literal::
+
+    name: raptor
+    manifest: testing/raptor/raptor/raptor.toml
+    metrics:
+        "First Paint":
+            description: "The description of the metric."
+            aliases:
+                - fcp
+                - anAliasForFCP
+            # Optional regex to match the metrics found in the tests with this
+            # documented metric
+            matcher: f.*
+    suites:
+        desktop:
+            description: "Desktop tests."
+            tests:
+                raptor-tp6: "Raptor TP6 tests."
+        mobile:
+            description: "Mobile tests"
+        benchmarks:
+            description: "Benchmark tests."
+            tests:
+                wasm: "All wasm tests."
+
+The documented metrics must exist in the tests for the suite. If they are not, then validation will fail. The same is true if a metric in a test is not documented. Also, if ``metrics`` are defined, then a ``metrics.rst`` file is expected to be found in the ``perfdocs`` folder for the given suite. It must contain the string ``{metrics_documentation}`` where the documentation should be added. The ``metrics.rst`` is renamed ``{suite-name}-metrics.rst`` in the generated folder, so if it needs to be linked to in the ``index.rst`` file, it should contain a ``{metrics_rst_name}`` string for where the link should be added - it's expected to be found in a toctree section.
+
 Note that there needs to be a FrameworkGatherer implemented for the framework being documented since each of them may have different ways of parsing test manifests for the tests. See `RaptorGatherer <https://searchfox.org/mozilla-central/source/tools/lint/perfdocs/framework_gatherers.py>`_ for an example gatherer that was implemented for Raptor.
 
 Sources
diff --git a/docs/code-quality/static-analysis/existing.rst b/docs/code-quality/static-analysis/existing.rst
index 9b20650ad0..dd38051dc7 100644
--- a/docs/code-quality/static-analysis/existing.rst
+++ b/docs/code-quality/static-analysis/existing.rst
@@ -96,7 +96,7 @@ Regression Testing
 
 In order to prevent regressions in our clang-tidy based static analysis,
 we have created a
-:searchfox:`task <taskcluster/ci/static-analysis-autotest/kind.yml>`
+:searchfox:`task <taskcluster/kinds/static-analysis-autotest/kind.yml>`
 on automation. This task runs on each commit and launches a test suite
 that is integrated into mach.
 
diff --git a/docs/conf.py b/docs/conf.py
index 72c25f464b..9b0c6cf41a 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -56,6 +56,7 @@ extensions = [
 # excluded from valid-jsdoc in the top-level .eslintrc.js.
 js_source_path = [
     "../browser/components/backup",
+    "../browser/components/backup/actors",
     "../browser/components/backup/resources",
     "../browser/components/extensions",
     "../browser/components/migration",
@@ -72,6 +73,7 @@ js_source_path = [
     "../toolkit/components/extensions",
     "../toolkit/components/extensions/parent",
     "../toolkit/components/featuregates",
+    "../toolkit/components/ml/content/ONNXPipeline.mjs",
     "../toolkit/mozapps/extensions",
     "../toolkit/components/prompts/src",
     "../toolkit/components/pictureinpicture",
diff --git a/docs/config.yml b/docs/config.yml
index cf3cea87e9..249a92d911 100644
--- a/docs/config.yml
+++ b/docs/config.yml
@@ -67,6 +67,7 @@ categories:
         - testing/webrender
         - testing/mochitest-plain
         - testing/xpcshell
+        - testing/tps
         - web-platform
         - gtest
         - tools/fuzzing
@@ -123,4 +124,4 @@ fatal warnings:
     - "WARNING: '([^']*)' reference target not found:((?!.rst).)*$"
     - "WARNING: Include file '([^']*)' not found or reading it failed"
 
-max_num_warnings: 837
+max_num_warnings: 845
diff --git a/docs/contributing/contribution_quickref.rst b/docs/contributing/contribution_quickref.rst
index f6f80e0cdf..9a9e5240e9 100644
--- a/docs/contributing/contribution_quickref.rst
+++ b/docs/contributing/contribution_quickref.rst
@@ -77,7 +77,7 @@ To Setup Firefox for Android
     $ curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py -O
     $ python3 bootstrap.py
 
-More information on :ref:`building Firefox for Android <fenix-contributor-guide>`
+More information on :ref:`building Firefox for Android <Firefox for Android>`
 
 To set up your editor
 ---------------------
diff --git a/docs/contributing/data-review.rst b/docs/contributing/data-review.rst
new file mode 100644
index 0000000000..93cc4067a6
--- /dev/null
+++ b/docs/contributing/data-review.rst
@@ -0,0 +1,41 @@
+Data Review
+-----------
+
+**Everything that lands in mozilla-central that adds or expands data
+collection must go through the data review process.**
+
+This will require assessing the sensitivity of the data that is being
+collected, and going through the `sensitive data collection
+process <https://wiki.mozilla.org/Data_Collection#Step_3:_Sensitive_Data_Collection_Review_Process>`__
+if necessary. All data collection is subject to our `overall data
+collection policy <https://wiki.mozilla.org/Data_Collection>`__.
+
+Documentation for the data collection request process and the
+expectations we have for people following it `lives on the
+wiki <https://wiki.mozilla.org/Data_Collection#Requesting_Data_Collection>`__.
+This document describes the technical implementation in Phabricator
+using tags.
+
+1. Any change that touches metrics will be automatically flagged with a
+   ``needs-data-classification`` tag by Phabricator, using `this herald
+   rule <https://phabricator.services.mozilla.com/H436>`__. If a change
+   adds/updates data collection in a way that doesn’t automatically
+   trigger this rule, this tag should be added manually (and if
+   appropriate, please file a bug to update the herald rule so it
+   happens automatically next time).
+
+2. After assessing data sensitivity, the tag can be replaced with either
+   ``data-classification-low`` or ``data-classification-high`` depending
+   on that sensitivity.
+
+3. Adding ``data-classification-high`` will auto-add the ``#data-stewards``
+   reviewer group as a blocking reviewer for the change and initiate the
+   `sensitive data review process <https://wiki.mozilla.org/Data_Collection#Step_3:_Sensitive_Data_Collection_Review_Process>`__.
+
+4. For patches making mechanical changes that happen to trigger the
+   herald rule linked above, but that do not actually add or update any
+   data collection, the ``data-classification-unnecessary`` tag can be used.
+
+Patches with the ``needs-data-classification`` tag will not be landable in
+Lando. The process linked above must be followed in order to land the
+change.
diff --git a/docs/contributing/how_to_submit_a_patch.rst b/docs/contributing/how_to_submit_a_patch.rst
index d8ef62f742..7c5b56a7e1 100644
--- a/docs/contributing/how_to_submit_a_patch.rst
+++ b/docs/contributing/how_to_submit_a_patch.rst
@@ -105,11 +105,6 @@ simple commit message should look like this:
 
    Bug 123456 - Change this thing to work better by doing something. r=reviewers
 
-The ``r=reviewers`` part is optional; if you are using Phabricator,
-Lando will add it automatically based on who actually granted review,
-and in any case the person who does the final check-in of the patch will
-make sure it's added.
-
 The text of the message should be what you did to fix the bug, not a
 description of what the bug was. If it is not obvious why this change is
 appropriate, then `explain why in the commit
@@ -117,6 +112,11 @@ message <https://mozilla-version-control-tools.readthedocs.io/en/latest/mozrevie
 If this does not fit on one line, then leave a blank line and add
 further lines for more detail and/or reasoning.
 
+The ``r=reviewers`` part specifies that ``reviewers`` should review the patch
+and provide feedback before it is integrated into the Firefox codebase. For
+choosing reviewers, and the full reviewer syntax, please see
+:ref:`Getting reviews`.
+
 You can edit the message of the current commit at any time using
 ``hg commit --amend`` or ``hg histedit``.
 
diff --git a/docs/contributing/index.rst b/docs/contributing/index.rst
index 3321b7f5f4..4b7cb7e23d 100644
--- a/docs/contributing/index.rst
+++ b/docs/contributing/index.rst
@@ -15,6 +15,7 @@ development process and source code documentation.
    reviews
    levelling-up
    how_to_submit_a_patch
+   data-review
 
 
 .. toctree::
diff --git a/docs/contributing/reviews.rst b/docs/contributing/reviews.rst
index 386872819c..8f026eec85 100644
--- a/docs/contributing/reviews.rst
+++ b/docs/contributing/reviews.rst
@@ -5,10 +5,37 @@ Getting reviews
 Thorough code reviews are one of Mozilla's ways of ensuring code quality.
 Every patch must be reviewed by the module owner of the code, or one of their designated peers.
 
-To request a review, you will need to specify a review group (starts with #). If there is not, you should select one or more usernames either when you submit the patch, or afterward in the UI.
-If you have a mentor, the mentor can usually either also review or find a suitable reviewer on your behalf.
+Commit message syntax
+---------------------
 
-For example, the syntax to request review from a group should be:
+When submitting your commit(s), use the following syntax to request review for your patch:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Request
+     - Syntax
+     - Description
+   * - Single reviewer
+     - ``r=reviewer``
+     - Request a review from a single reviewer (``reviewer``). Historically, the syntax ``r?reviewer`` requested a review, and ``r=reviewer`` marked the reviewer who accepted the patch before landing. Both can now be used interchangeably when requesting a review.
+   * - Multiple reviewers
+     - ``r=reviewer1,reviewer2``
+     - Request reviews from *both* ``reviewer1`` and ``reviewer2``.
+   * - Blocking review
+     - ``r=reviewer!``
+     - Request a *blocking* review from ``reviewer``. This means that ``reviewer`` *must* review the patch before it can be landed.
+   * - Both optional and blocking reviews
+     - ``r=reviewer1,reviewer2!``
+     - Request a *blocking* review from ``reviewer2``, and an *optional* review from ``reviewer1``.
+   * - Review groups
+     - ``r=#review-group``
+     - Request a review from members of ``#review-group``. A full list can be found below.
+   * - Blocking review groups
+     - ``r=#review-group!``
+     - Request a blocking review from a review group. This will require *at least one member* of the group to approve before landing.
+
+For example, the commit syntax to request review from group ``group-name`` or ``developer-nickname`` would be:
 
 .. code-block::
 
@@ -18,12 +45,30 @@ For example, the syntax to request review from a group should be:
 
      Bug xxxx - explain what you are doing and why r?developer-nickname
 
-Getting attention: If a reviewer doesn't respond within a week, or so of the review request:
+Reviews, and review groups, can be selected or adjusted after submission in the phabricator UI.
+
+Sometimes when publishing a patch, groups will automatically be added as blocking reviewers due to the code being touched. In this case, you may want to check that the reviewers you requested review from are set to blocking as well.
+
+Choosing reviewers
+------------------
+
+* If you have a mentor assigned on the bug you are fixing, the mentor can usually either also review or find a suitable reviewer on your behalf.
+* If you do not have a mentor, see if your code fits into one of the review groups below, and request review from that group.
+* Otherwise, try looking at the history of the file to see who has modified it recently. (For example, `hg log <modified-file>` or `git log <modified-file>`)
+* Finally if you are still unable to identify someone, try asking in the `#introduction channel on Matrix <https://chat.mozilla.org/#/room/#introduction:mozilla.org>`_.
+
+
+Getting attention
+-----------------
+
+Generally most reviews will happen within roughly a week. If, however, a reviewer doesn't respond within a week or so of the review request:
 
   * Contact the reviewer directly (either via e-mail or on Matrix).
   * Join developers on `Mozilla's Matrix server <https://chat.mozilla.org>`_, and ask if anyone knows why a review may be delayed. Please link to the bug too.
   * If the review is still not addressed, mail the reviewer directly, asking if/when they'll have time to review the patch, or might otherwise be able to review it.
 
+Remember that reviewers are human too, and may have complex reasons that prevent them from reviewing your patch in a timely manner. Be confident in reaching out to your reviewer, but be mindful of the `Mozilla Community Participation Guidelines <https://www.mozilla.org/en-US/about/governance/policies/participation/>`_ while doing so.
+
 For simple documentation changes, reviews are not required.
 
 For more information about the review process, see the :ref:`Code Review FAQ`.
diff --git a/docs/contributing/signing/signing_macos_build.rst b/docs/contributing/signing/signing_macos_build.rst
index 688a935bbe..ef5e5f3ab3 100644
--- a/docs/contributing/signing/signing_macos_build.rst
+++ b/docs/contributing/signing/signing_macos_build.rst
@@ -127,7 +127,7 @@ Example: Re-Signing Official Nightly
     0:00.20 Using ad-hoc signing identity
     0:00.20 Using nightly channel signing configuration
     0:00.20 Using developer entitlements
-    0:00.20 Reading build config file /Users/me/r/mc/taskcluster/ci/config.yml
+    0:00.20 Reading build config file /Users/me/r/mc/taskcluster/config.yml
     0:00.23 Stripping existing xattrs and signatures
     0:01.91 Signing with codesign
     0:02.72 Verification of signed app /Users/me/Desktop/FirefoxNightly.app OK
@@ -149,7 +149,7 @@ can be exported from Keychain Access in .p12 format.
     0:00.26 Using pkcs12 signing identity
     0:00.26 Using devedition channel signing configuration
     0:00.26 Using developer entitlements
-    0:00.26 Reading build config file /Users/me/r/mc/taskcluster/ci/config.yml
+    0:00.26 Reading build config file /Users/me/r/mc/taskcluster/config.yml
     0:00.29 Stripping existing xattrs and signatures
     0:02.09 Signing with rcodesign
     0:11.16 Verification of signed app /Users/me/Desktop/DevEdition.app OK
diff --git a/docs/overview/ios.rst b/docs/overview/ios.rst
index a16e0676bd..e52a3953ee 100644
--- a/docs/overview/ios.rst
+++ b/docs/overview/ios.rst
@@ -20,6 +20,6 @@ WKWebView
 ---------
 
 WKWebView is part of Apple`s WebKit framework. It supports a complete web browsing experience,
-rendering HTML, CSS, and JavaScrip content alongside an app`s native views. It can also be thought
+rendering HTML, CSS, and JavaScript content alongside an app`s native views. It can also be thought
 of as an API to help render web pages on Apple platforms. For more information on WKWebView itself,
 please see `Apple's documentation <https://developer.apple.com/documentation/webkit/wkwebview>`_.
diff --git a/docs/setup/common_build_errors.md b/docs/setup/common_build_errors.md
new file mode 100644
index 0000000000..3267c96937
--- /dev/null
+++ b/docs/setup/common_build_errors.md
@@ -0,0 +1,34 @@
+# Common Build Errors
+
+When setting up Firefox, you may encounter some other build errors or
+warnings that are not fatal. This document is to help you determine
+if the error you're running into is a fatal one or not.
+
+## Watchman unavailable
+
+This is a warning and can be ignored.
+[Watchman is a file watching service](https://facebook.github.io/watchman/)
+that can speed up some interactions with Git and Mercurial.
+
+## VSCode Java extension
+
+If you happen to have the Java extension installed in VSCode, there's
+a chance that the "Problems" tab  in the integrated terminal will
+display an error about `Cannot run program [...]/mozilla-unified/mach`.
+This is because the extension does not know how to parse the mozilla-central
+repository and specifically the `mach` command runner.
+This will not prevent you from building and running Firefox.
+
+## ERROR glean_core
+
+This is a non-fatal error and will not prevent you from building and
+running Firefox. You might see this text in the console after running
+`./mach run`. The specific text might appear as:
+`Error setting metrics feature config: [...]`.
+
+## Region.sys.mjs
+
+This is a non-fatal error, this will not prevent you from building and
+running Firefox. You might see this text in the console after running
+`./mach run` and the specific text might look like:
+`console.error: Region.sys.mjs: Error fetching region`.
diff --git a/docs/setup/index.rst b/docs/setup/index.rst
index eb0c68aa4e..3cd6d3f229 100644
--- a/docs/setup/index.rst
+++ b/docs/setup/index.rst
@@ -18,6 +18,7 @@ Don't hesitate to look at the :ref:`Firefox Contributors Quick Reference <Firefo
    macos_build
    linux_build
    linux_32bit_build_on_64bit_OS
+   common_build_errors
 
 .. toctree::
    :caption: Getting Ready To Contribute
diff --git a/docs/setup/macos_build.rst b/docs/setup/macos_build.rst
index df3719e648..b4b940af68 100644
--- a/docs/setup/macos_build.rst
+++ b/docs/setup/macos_build.rst
@@ -127,7 +127,7 @@ To test your changes on another macOS system (or to keep that particular Firefox
 
    ./mach package
 
-Copy the resulting ``.dmg`` file from ``obj-*/dist/`` to the target system, then double-click it as usual to find an ``.app`` bundle containing all dependencies.
+Copy the resulting ``.dmg`` file from ``obj-*/dist/`` to the target system, then double-click it as usual to find an ``.app`` bundle containing all dependencies. In newer versions of MacOS you will need to sign the package for this to work using :ref:`Signing Local macOS Builds`.
 
 Now the fun starts
 ------------------
diff --git a/docs/writing-rust-code/update-policy.md b/docs/writing-rust-code/update-policy.md
index b23e7b6e22..60eed74e94 100644
--- a/docs/writing-rust-code/update-policy.md
+++ b/docs/writing-rust-code/update-policy.md
@@ -152,9 +152,9 @@ Here are the Rust versions for each Firefox version.
 | Firefox 123 | Rust 1.75.0 | 1.70.0 | 2023 December 28 | 2024 January 11 | 2024 February 20
 | Firefox 124 | Rust 1.76.0 | 1.70.0 | 2024 February 8 | 2024 February 15 | 2024 March 19
 | Firefox 125 | Rust 1.76.0 | 1.74.0 | 2024 February 8 | 2024 March 14 | 2024 April 16
+| Firefox 126 | Rust 1.77.2 | 1.74.0 | 2024 March 28 | 2024 April 11 | 2024 May 14
 | **Estimated** |
-| Firefox 126 | Rust 1.77.2 | ? | 2024 March 28 | 2024 April 11 | 2024 May 14
-| Firefox 127 | Rust 1.78.0 | ? | 2024 May 2 | 2024 May 9 | 2024 June 11
+| Firefox 127 | Rust 1.78.0 | 1.76.0 | 2024 May 2 | 2024 May 9 | 2024 June 11
 | Firefox 128 | Rust 1.78.0 | ? | 2024 May 2 | 2024 June 6 | 2024 July 9
 | Firefox 129 | Rust 1.79.0 | ? | 2024 June 13 | 2024 July 4 | 2024 August 6
 | Firefox 130 | Rust 1.80.0 | ? | 2024 July 25 | 2024 August 1 | 2024 September 3