From a2ce5437cef58ba0fdccf7d469874a332b417bfe Mon Sep 17 00:00:00 2001
From: Sylvestre Ledru <sylvestre@debian.org>
Date: Thu, 30 Apr 2026 12:05:18 +0000
Subject: [PATCH] Bug 2024589 - doc: use the :searchfox: macro
 r=asuth,perftest-reviewers,necko-reviewers,mozperftest-reviewers,geckoview-reviewers,extension-reviewers,credential-management-reviewers,search-reviewers,releng-reviewers,places-reviewers,profiler-reviewers,win-reviewers,omc-reviewers,urlbar-reviewers,permissions-reviewers,core-sessionstore-reviewers,browser-installer-reviewers,layout-reviewers,dom-worker-reviewers,ai-platform-reviewers,niklas,sthompson,janerik,bhearsum,valentin,dshin,sparky,scunnane,canaltinova,hanna_a,handyman,ahal,farre,jteow,emz,nrishel,ohall,dimi,robwu,emilio

Differential Revision: https://phabricator.services.mozilla.com/D288640
---
 browser/branding/docs/index.rst               |   2 +-
 .../components/backup/docs/architecture.rst   |   4 +-
 .../places/docs/architecture-overview.rst     |  63 ++---
 .../places/docs/notifyObservers.rst           |   7 +-
 browser/components/search/docs/index.rst      |   3 +-
 browser/components/search/docs/telemetry.rst  |   2 +-
 browser/components/touchbar/docs/index.rst    |  15 +-
 .../urlbar/docs/dynamic-result-types.rst      |   8 +-
 browser/components/urlbar/docs/index.rst      |   2 +-
 browser/components/urlbar/docs/lifetime.rst   |  36 +--
 .../urlbar/docs/nontechnical-overview.rst     |   4 +-
 browser/components/urlbar/docs/overview.rst   |  12 +-
 .../components/urlbar/docs/ranking-legacy.rst |   4 +-
 browser/components/urlbar/docs/ranking.rst    |   4 +-
 browser/components/urlbar/docs/telemetry.rst  |   2 +-
 browser/components/urlbar/docs/testing.rst    |  25 +-
 browser/components/urlbar/docs/utilities.rst  |   4 +-
 browser/docs/BrowserUsageTelemetry.rst        |   4 +-
 browser/docs/CommandLineParameters.rst        |   3 +-
 .../extensions/formautofill/docs/index.rst    |  18 +-
 .../installer/windows/docs/FullInstaller.rst  |   4 +-
 browser/installer/windows/docs/Helper.rst     |   6 +-
 .../installer/windows/docs/InstallerBuild.rst |   2 +-
 browser/installer/windows/docs/MSI.rst        |   2 +-
 browser/installer/windows/docs/StubArch.rst   |   2 +-
 build/docs/flatpak.rst                        |   2 +-
 build/docs/jar-manifests.rst                  |  20 +-
 build/docs/rust.rst                           |  13 +-
 build/docs/snap.rst                           |  11 +-
 build/docs/test_certificates.rst              |   4 +-
 build/docs/toolchains.rst                     |  48 +---
 .../coding-style/coding_style_cpp.rst         |   2 +-
 .../format_cpp_code_with_clang-format.rst     |   9 +-
 .../coding-style/rtl_guidelines.rst           |  21 +-
 .../using_cxx_in_firefox_code.rst             |   9 +-
 docs/code-quality/index.rst                   |   2 +-
 docs/code-quality/lint/create.rst             |  18 +-
 docs/code-quality/lint/linters/clippy.rst     |   6 +-
 .../rules/reject-importGlobalProperties.rst   |   2 +-
 .../reject-scriptableunicodeconverter.rst     |   4 +-
 docs/code-quality/lint/linters/eslint.rst     |   7 +-
 .../code-quality/lint/linters/gecko-trace.rst |   4 +-
 docs/code-quality/lint/linters/license.rst    |   3 +-
 docs/code-quality/lint/linters/perfdocs.rst   |   6 +-
 docs/code-quality/lint/linters/ruff.rst       |   7 +-
 .../lint/linters/test-manifest-toml.rst       |   4 +-
 .../writing-new/adding-a-check.rst            |   4 +-
 .../writing-new/advanced-check-features.rst   |   2 +-
 .../writing-new/clang-query.rst               |   3 +-
 docs/content-security/index.rst               |   6 +-
 .../build/building_mobile_firefox.rst         |   4 +-
 docs/contributing/contributing_to_mozilla.rst |   2 +-
 .../debugging/debugging_firefox_with_lldb.rst |   4 +-
 .../debugging_firefox_with_valgrind.rst       |   2 +-
 .../debugging/debugging_on_macos.rst          |   6 +-
 .../debugging/debugging_on_windows.rst        |   2 +-
 .../debugging/debugging_webrtc_calls.rst      |  70 ++---
 docs/contributing/editors/vscode.rst          |   2 +-
 docs/jsloader/jsloader-api.rst                |   4 +-
 docs/jsloader/system-modules.rst              |  10 +-
 docs/nspr/reference/pr_extern.rst             |   2 +-
 docs/nspr/reference/pr_implement.rst          |   2 +-
 docs/nspr/reference/prfileinfo.rst            |   4 +-
 docs/nspr/reference/prfileinfo64.rst          |   4 +-
 docs/nspr/reference/print32.rst               |   2 +-
 docs/nspr/reference/print64.rst               |   2 +-
 docs/nspr/reference/pruint32.rst              |   2 +-
 docs/nspr/reference/pruint64.rst              |   2 +-
 docs/overview/gecko.rst                       |  10 +-
 docs/setup/building_with_debug_symbols.rst    |   2 +-
 docs/setup/macos_build.rst                    |   2 +-
 dom/docs/ipc/jsactors.rst                     |  10 +-
 dom/docs/ipc/process_model.rst                |  18 +-
 dom/docs/navigation/BrowsingContext.rst       |  20 +-
 dom/docs/workersAndStorage/CodeStyle.rst      |   2 +-
 .../workersAndStorage/PerformanceTesting.rst  |  15 +-
 editor/docs/IMEHandlingGuide.rst              |  96 ++++---
 extensions/permissions/docs/manager.rst       |   9 +-
 extensions/permissions/docs/remote.rst        |   3 +-
 gfx/docs/AsyncPanZoom.rst                     |  20 +-
 intl/docs/icu.rst                             |   2 +-
 ipc/docs/ipdl.rst                             |  30 +-
 ipc/docs/processes.rst                        | 262 +++++++-----------
 ipc/docs/utility_process.rst                  |  18 +-
 layout/docs/LayoutCodeReviewerChecklist.rst   |   3 +-
 layout/docs/index.rst                         |   3 +-
 .../consumer/geckoview-quick-start.rst        |   2 +-
 .../docs/geckoview/consumer/permissions.rst   |   2 +-
 .../geckoview/consumer/web-extensions.rst     |   4 +-
 .../contributor/for-gecko-engineers.rst       |   2 +-
 .../contributor/geckoview-architecture.rst    |  53 ++--
 .../contributor/geckoview-quick-start.rst     |   2 +-
 .../docs/geckoview/contributor/junit.rst      | 102 +++----
 .../docs/geckoview/design/save-to-pdf.rst     |   2 +-
 mobile/android/docs/geckoview/index.rst       |   2 +-
 mobile/android/docs/index.rst                 |   2 +-
 netwerk/docs/cache2/doc.rst                   |  13 +-
 netwerk/docs/http/lifecycle.rst               |  91 +++---
 netwerk/docs/http_server_for_testing.rst      |   6 +-
 python/mach/docs/usage.rst                    |   2 +-
 python/mozperftest/perfdocs/vision.rst        |   4 +-
 python/mozperftest/perfdocs/writing.rst       |  12 +-
 services/sync/docs/engines.rst                |   6 +-
 services/sync/docs/overview.rst               |   2 +-
 services/sync/docs/rust-engines.rst           |   4 +-
 taskcluster/docs/kinds/test.rst               |   5 +-
 taskcluster/docs/optimization/index.rst       |   4 +-
 taskcluster/docs/release-promotion-action.rst |  13 +-
 taskcluster/docs/taskgraph.rst                |   6 +-
 taskcluster/docs/transforms/index.rst         |   3 +-
 testing/docs/automated-testing/index.rst      |  12 +-
 .../automated-testing/manifest-sandbox.rst    |  12 +-
 testing/docs/chrome-tests/index.rst           |   5 +-
 testing/docs/tests-for-new-config/index.rst   |   6 +-
 testing/docs/tests-for-new-config/manual.rst  |   6 +-
 testing/docs/xpcshell/index.rst               |   2 +-
 testing/mozbase/docs/manifestparser.rst       |   4 +-
 testing/perfdocs/generated/browsertime.rst    |  25 +-
 testing/perfdocs/generated/debugging.rst      |   4 +-
 .../perfdocs/generated/telemetry-alerting.rst |   2 +-
 testing/perfdocs/generated/writing.rst        |   8 +-
 .../mach-try-perf/perfdocs/index.rst          |   2 +-
 .../telemetry-alerting/perfdocs/index.rst     |   2 +-
 .../raptor/raptor/perfdocs/browsertime.rst    |  31 +--
 .../raptor/raptor/perfdocs/contributing.rst   |   2 +-
 testing/raptor/raptor/perfdocs/debugging.rst  |  16 +-
 testing/raptor/raptor/perfdocs/index.rst      |   2 +-
 testing/raptor/raptor/perfdocs/test-list.rst  |   4 +-
 .../raptor/raptor/perfdocs/webextension.rst   |  10 +-
 testing/talos/perfdocs/index.rst              |  17 +-
 .../components/autocomplete/docs/index.rst    |  48 ++--
 .../crashes/docs/crash-ping-lifecycle.rst     |  23 +-
 toolkit/components/extensions/docs/basics.rst |   8 +-
 .../components/extensions/docs/incognito.rst  |   4 +-
 toolkit/components/extensions/docs/other.rst  |   2 +-
 .../extensions/docs/webext-storage.rst        |   6 +-
 .../extensions/docs/webidl_bindings.rst       |   7 +-
 .../messaging-system/schemas/index.rst        |  62 ++---
 toolkit/components/ml/docs/models.rst         |   4 +-
 .../pictureinpicture/docs/index.rst           |  10 +-
 .../docs/nsIPromptService-reference.rst       |   2 +-
 .../docs/implementation.rst                   |   2 +-
 .../search/docs/SearchConfigurationSchema.rst |   6 +-
 .../docs/SearchConfigurationSchemaArchive.rst |   7 +-
 .../search/docs/SearchEngineConfiguration.rst |   3 +-
 .../docs/SearchEngineConfigurationArchive.rst |   3 +-
 .../search/docs/SearchEnginesArchive.rst      |   3 +-
 .../docs/SearchServiceHighlevelOverview.rst   |  12 +-
 .../SearchServiceHighlevelOverviewArchive.rst |  16 +-
 .../sessionstore/docs/collection.rst          |  16 +-
 .../sessionstore/docs/restoredata.rst         |   6 +-
 .../components/sessionstore/docs/utils.rst    |   4 +-
 .../telemetry/docs/data/main-ping.rst         |   6 +-
 .../telemetry/docs/data/new-profile-ping.rst  |   2 +-
 .../internals/integration_tests/index.rst     |   2 +-
 .../docs/obsolete/collection/events.rst       |   2 +-
 .../docs/obsolete/collection/histograms.rst   |   6 +-
 .../docs/obsolete/collection/scalars.rst      |  14 +-
 .../obsolete/collection/user-interactions.rst |   2 +-
 .../docs/start/adding-a-new-probe.rst         |  12 +-
 .../docs/Using_the_Mozilla_symbol_server.rst  |   2 +-
 toolkit/modules/docs/Region.rst               |  11 +-
 .../mozapps/update/docs/BackgroundUpdates.rst |   9 +-
 .../update/docs/InAppUpdateProcess.rst        |   4 +-
 tools/code-coverage/docs/index.rst            |   2 +-
 tools/fuzzing/docs/fuzzing_interface.rst      |  16 +-
 tools/fuzzing/docs/index.rst                  |   7 +-
 tools/lint/perfdocs/framework_gatherers.py    |   2 +-
 tools/moztreedocs/docs/architecture.rst       |  14 +-
 tools/moztreedocs/docs/redirect.rst           |   2 +-
 tools/profiler/docs/buffer.rst                |   8 +-
 tools/profiler/docs/code-overview.rst         |  76 ++---
 tools/profiler/docs/instrumenting-android.rst |   9 +-
 tools/profiler/docs/instrumenting-rust.rst    |   9 +-
 tools/profiler/docs/markers-guide.rst         |  18 +-
 tools/profiler/docs/memory.rst                |   6 +-
 tools/sanitizer/docs/tsan.rst                 |   2 +-
 tools/tryselect/docs/presets.rst              |   4 +-
 tools/update-verify/docs/index.rst            |   6 +-
 uriloader/docs/uriloader.rst                  |   4 +-
 widget/windows/docs/blocklist.rst             |  11 +-
 .../docs/windows-pointing-device/index.rst    |   2 +-
 xpcom/docs/collections.rst                    |   4 +-
 xpcom/docs/hashtables.rst                     |   7 +-
 xpcom/docs/hashtables_detailed.rst            |  13 +-
 xpcom/docs/mozpromise.rst                     |   8 +-
 xpcom/docs/stringguide.rst                    |   6 +-
 xpcom/docs/writing-xpcom-interface.rst        |   8 +-
 188 files changed, 939 insertions(+), 1253 deletions(-)

diff --git a/browser/branding/docs/index.rst b/browser/branding/docs/index.rst
index d09ee321ec14..0ca5feeac5f6 100644
--- a/browser/branding/docs/index.rst
+++ b/browser/branding/docs/index.rst
@@ -6,7 +6,7 @@ Firefox has multiple different sets of "branding" that are used to hold channel-
 * Product names (eg: "Mozilla Firefox", "Firefox Developer Edition")
 * Channel-specific preferences (eg: ``app.update.interval``)
 
-Brandings are stored in the `branding subdirectory <https://searchfox.org/firefox-main/source/browser/branding>`_ and map to builds as follows:
+Brandings are stored in the :searchfox:`branding subdirectory <browser/branding>` and map to builds as follows:
 
 - ``official`` is used for Release and Beta builds
 - ``aurora`` is used for Developer Edition builds
diff --git a/browser/components/backup/docs/architecture.rst b/browser/components/backup/docs/architecture.rst
index 3f108eea87bf..ab108076c79b 100644
--- a/browser/components/backup/docs/architecture.rst
+++ b/browser/components/backup/docs/architecture.rst
@@ -5,9 +5,7 @@ The ``BackupService`` module is architected in a way to make testing its
 individual components relatively easy with unit tests.
 
 The main entry point exists in a module called
-``BackupService.sys.mjs``, which is `invoked and initialized via in the
-BrowserGlue idle tasks
-list <https://searchfox.org/mozilla-central/rev/97feebcab27f1a92e70ceacaa77211e9eaba0e6e/browser/components/BrowserGlue.sys.mjs#2449-2470>`__
+``BackupService.sys.mjs``, which is :searchfox:`invoked and initialized via in the BrowserGlue idle tasks list <mozilla-central/rev/97feebcab27f1a92e70ceacaa77211e9eaba0e6e:browser/components/BrowserGlue.sys.mjs#2449-2470>`
 
 The ``BackupService`` manages two high-level operations: creation of
 backups, and recovery from such backups.
diff --git a/browser/components/places/docs/architecture-overview.rst b/browser/components/places/docs/architecture-overview.rst
index 4616ce005041..df4d87421a34 100644
--- a/browser/components/places/docs/architecture-overview.rst
+++ b/browser/components/places/docs/architecture-overview.rst
@@ -14,57 +14,38 @@ Frontend
 --------
 
 The frontend part of the bookmarking experience includes various kind of views:
-  * `Trees`_
-  * `Menus`_
-  * `Toolbars`_
+  * :searchfox:`Trees <browser/components/places/content/places-tree.js>`
+  * :searchfox:`Menus <mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1:browser/components/places/content/browserPlacesViews.js#1990>`
+  * :searchfox:`Toolbars <mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1:browser/components/places/content/browserPlacesViews.js#894>`
 
-  .. _Trees: https://searchfox.org/firefox-main/source/browser/components/places/content/places-tree.js
-  .. _Menus: https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/browser/components/places/content/browserPlacesViews.js#1990
-  .. _Toolbars: https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/browser/components/places/content/browserPlacesViews.js#894
+All the views share a common :searchfox:`Controller <browser/components/places/content/controller.js>` that is responsible to handle operations and commands required by the views. Each view creates a Result object and receives notifications about changes from it.
 
-All the views share a common `Controller`_ that is responsible to handle operations and commands required by the views. Each view creates a Result object and receives notifications about changes from it.
+As an example, removing a bookmark from a view will call into the controller that calls into PlacesTransactions to actually do the removal. The removal will notify a :searchfox:`Places event <dom/chrome-webidl/PlacesEvent.webidl>`, that is caught by the Result, that will immediately update its internal representation of the bookmarks tree. Then the Result sends a notification to the view that will handle it, updating what the user is seeing. The system works according to the classical `Model-View-Controller`_ pattern.
 
-As an example, removing a bookmark from a view will call into the controller that calls into PlacesTransactions to actually do the removal. The removal will notify a `Places event`_, that is caught by the Result, that will immediately update its internal representation of the bookmarks tree. Then the Result sends a notification to the view that will handle it, updating what the user is seeing. The system works according to the classical `Model-View-Controller`_ pattern.
+Fronted dialogs and panels are written using xhtml and shadow DOM. The bookmark dialogs in particular are wrappers around a common template, :searchfox:`editBookmarkPanel.inc.xhtml <browser/components/places/content/editBookmarkPanel.inc.xhtml>`, it could be extended or overloaded like an object (overlay, similar to Web Component).
 
-Fronted dialogs and panels are written using xhtml and shadow DOM. The bookmark dialogs in particular are wrappers around a common template, `editBookmarkPanel.inc.xhtml`_, it could be extended or overloaded like an object (overlay, similar to Web Component).
+Most of the logic for the edit bookmark overlay lives in the generic script :searchfox:`editBookmark.js <browser/components/places/content/editBookmark.js>`.
 
-Most of the logic for the edit bookmark overlay lives in the generic script `editBookmark.js`_.
-
-.. _Controller: https://searchfox.org/firefox-main/source/browser/components/places/content/controller.js
-.. _Places event: https://searchfox.org/firefox-main/source/dom/chrome-webidl/PlacesEvent.webidl
 .. _Model-View-Controller: https://en.wikipedia.org/wiki/Model–view–controller
-.. _editBookmarkPanel.inc.xhtml: https://searchfox.org/firefox-main/source/browser/components/places/content/editBookmarkPanel.inc.xhtml
-.. _editBookmark.js: https://searchfox.org/firefox-main/source/browser/components/places/content/editBookmark.js
 
 Structure of Frontend
 ^^^^^^^^^^^^^^^^^^^^^
 
-Most part of frontend code is located in : `Browser/Components/Places/Content`_:
+Most part of frontend code is located in : :searchfox:`Browser/Components/Places/Content <browser/components/places/content>`:
 
-  - `BookmarkProperties`_ , BookmarkProperties.xhtml - responsible for editBookmarks & newBookmark Dialog. The panel is initialized based on data given in the js object passed as ``window.arguments[0]``. ``Window.arguments[0]`` is set to the guid of the item, if the dialog is accepted.
+  - :searchfox:`BookmarkProperties <browser/components/places/content/bookmarkProperties.js>` , BookmarkProperties.xhtml - responsible for editBookmarks & newBookmark Dialog. The panel is initialized based on data given in the js object passed as ``window.arguments[0]``. ``Window.arguments[0]`` is set to the guid of the item, if the dialog is accepted.
   - BookmarksHistoyTooltip.xhtml - code responsible for tooltip
-  - `BookmarksSidebar`_, bookmarksSidebar.xhtml - code responsible for sidebar window. Searches through existing bookmarks tree for desired bookmark.
-  - `BrowserPlacesViews`_ - controls most views (menu, panels, toolbox). The base view implements everything that's common to the toolbar and menu views.
-  - `Controller`_ - controller shared by all places views. Connect UI and actual operations.
-  - `EditBookmark`_, editBookmarkPanel.inc.xhtml - controls edit bookmark panel. Observes changes for bookmarks and connects all UI manipulations with backend.
-  - `HistorySidebar`_, historySidebar.xhtml - code responsible for history sidebar window. Searches through existing tree for requested History.
-  - `Places-menupopup`_ - custom element definition for Places menus
-  - `Places-tree`_ - class ``MozPlacesTree`` - builds a custom element definition for the places tree. This is loaded into all XUL windows. Has to be wrapped in a block to prevent leaking to a window scope.
+  - :searchfox:`BookmarksSidebar <browser/components/places/content/bookmarksSidebar.js>`, bookmarksSidebar.xhtml - code responsible for sidebar window. Searches through existing bookmarks tree for desired bookmark.
+  - :searchfox:`BrowserPlacesViews <browser/components/places/content/browserPlacesViews.js>` - controls most views (menu, panels, toolbox). The base view implements everything that's common to the toolbar and menu views.
+  - :searchfox:`Controller <browser/components/places/content/controller.js>` - controller shared by all places views. Connect UI and actual operations.
+  - :searchfox:`EditBookmark <browser/components/places/content/editBookmark.js>`, editBookmarkPanel.inc.xhtml - controls edit bookmark panel. Observes changes for bookmarks and connects all UI manipulations with backend.
+  - :searchfox:`HistorySidebar <browser/components/places/content/historySidebar.js>`, historySidebar.xhtml - code responsible for history sidebar window. Searches through existing tree for requested History.
+  - :searchfox:`Places-menupopup <browser/components/places/content/places-menupopup.js>` - custom element definition for Places menus
+  - :searchfox:`Places-tree <browser/components/places/content/places-tree.js>` - class ``MozPlacesTree`` - builds a custom element definition for the places tree. This is loaded into all XUL windows. Has to be wrapped in a block to prevent leaking to a window scope.
   - Places.css, places.js, places.xhtml - responsible for Library window
   - PlacesCommands.inc.xhtml - commands for multiple windows
   - PlacesContextMenu.inc.xhtml - definition for context menu
-  - `TreeView`_ - implementation of the tree view
-
-  .. _Browser/Components/Places/Content: https://searchfox.org/firefox-main/source/browser/components/places/content
-  .. _BookmarkProperties: https://searchfox.org/firefox-main/source/browser/components/places/content/bookmarkProperties.js
-  .. _BookmarksSidebar: https://searchfox.org/firefox-main/source/browser/components/places/content/bookmarksSidebar.js
-  .. _BrowserPlacesViews: https://searchfox.org/firefox-main/source/browser/components/places/content/browserPlacesViews.js
-  .. _EditBookmark: https://searchfox.org/firefox-main/source/browser/components/places/content/editBookmark.js
-  .. _HistorySidebar: https://searchfox.org/firefox-main/source/browser/components/places/content/historySidebar.js
-  .. _Places-menupopup: https://searchfox.org/firefox-main/source/browser/components/places/content/places-menupopup.js
-  .. _Places-tree: https://searchfox.org/firefox-main/source/browser/components/places/content/places-tree.js
-  .. _TreeView: https://searchfox.org/firefox-main/source/browser/components/places/content/treeView.js
-
+  - :searchfox:`TreeView <browser/components/places/content/treeView.js>` - implementation of the tree view
 
 Backend
 -------
@@ -78,21 +59,18 @@ Toolkit Places also provides a way to query bookmarks, through Results. This is
 Structure of Backend
 ^^^^^^^^^^^^^^^^^^^^
 
-Most part of backend code is located in : `Toolkit/Components/Places`_:
+Most part of backend code is located in : :searchfox:`Toolkit/Components/Places <toolkit/components/places>`:
 
   - :doc:`Bookmarks` - Asynchronous API for managing bookmarks
   - :doc:`History` - Asynchronous API for managing history
-  - `PlacesUtils`_ - This module exports functions for Sync to use when applying remote records
+  - :searchfox:`PlacesUtils <toolkit/components/places/PlacesUtils.sys.mjs>` - This module exports functions for Sync to use when applying remote records
   - :doc:`PlacesTransactions` - This module serves as the transactions manager for Places
 
-  .. _Toolkit/Components/Places: https://searchfox.org/firefox-main/source/toolkit/components/places
-  .. _PlacesUtils: https://searchfox.org/firefox-main/source/toolkit/components/places/PlacesUtils.sys.mjs
-
 Storage
 -------
 
 Places uses `SQLite`_ (C-language library with a stable, cross-platform, and backwards compatible file format) as its data storage backend.
-All the data is contained in a places.sqlite file, in the roaming Firefox profile folder. The database is accessed using a wrapper of the SQLite library called `mozStorage`_.
+All the data is contained in a places.sqlite file, in the roaming Firefox profile folder. The database is accessed using a wrapper of the SQLite library called :searchfox:`mozStorage <storage>`.
 For storing our favicons we use favicons.sqlite which is represented as ATTACH-ed to places.sqlite. That makes it easier to use our two separate sqlites as one single database.
 
 Synchronization
@@ -101,5 +79,4 @@ Synchronization
 Places works in strict contact with `Firefox Sync`_, to synchronize bookmarks and history across devices, thus you can meet Sync specific code in various parts of the Places codebase. Some of the code may refer to Weave, the old project name for Sync.
 
 .. _SQLite: https://www.sqlite.org/index.html
-.. _mozStorage: https://searchfox.org/firefox-main/source/storage
 .. _Firefox Sync: https://www.mozilla.org/en-US/firefox/sync/
diff --git a/browser/components/places/docs/notifyObservers.rst b/browser/components/places/docs/notifyObservers.rst
index 156d49b1a2d1..9a18188f7937 100644
--- a/browser/components/places/docs/notifyObservers.rst
+++ b/browser/components/places/docs/notifyObservers.rst
@@ -10,8 +10,8 @@ Generally - the Observer pattern follows a subscription model. A subscriber (com
 
 Each successful operation is noticed by observer for these events and passed to a subscriber.
 
-`PlacesObservers.webidl`_ a Global Singleton which provides utilities to observe or notify all events.
-`PlacesEvent.webidl`_ states all types of possible events and describes their features. In our case, events are:
+:searchfox:`PlacesObservers.webidl <dom/chrome-webidl/PlacesObservers.webidl>` a Global Singleton which provides utilities to observe or notify all events.
+:searchfox:`PlacesEvent.webidl <dom/chrome-webidl/PlacesEvent.webidl>` states all types of possible events and describes their features. In our case, events are:
 
   - ``“page-visited”`` - ``data: PlacesVisit`` Fired whenever a page is visited
   - ``“bookmark-added”`` - ``data: PlacesBookmarkAddition`` Fired whenever a bookmark (or a bookmark folder/separator) is created.
@@ -30,6 +30,3 @@ Each successful operation is noticed by observer for these events and passed to
   - ``“page-rank-changed”`` - ``data: PlacesRanking`` Fired whenever pages ranking is changed.
   - ``“page-removed”`` - ``data: PlacesVisitRemoved`` Fired whenever a page or its visits are removed. This may be invoked when a page is removed from the store because it has no more visits, nor bookmarks. It may also be invoked when all or some of the page visits are removed, but the page itself is not removed from the store, because it may be bookmarked.
   - ``“purge-caches”`` - ``data: PlacesPurgeCaches`` Fired whenever changes happened that could not be observed through other notifications, for example a database fixup. When received, observers, especially data views, should drop any caches and reload from scratch.
-
-  .. _PlacesObservers.webidl: https://searchfox.org/firefox-main/source/dom/chrome-webidl/PlacesObservers.webidl
-  .. _PlacesEvent.webidl: https://searchfox.org/firefox-main/source/dom/chrome-webidl/PlacesEvent.webidl
diff --git a/browser/components/search/docs/index.rst b/browser/components/search/docs/index.rst
index e951f6626df5..a0057fb37962 100644
--- a/browser/components/search/docs/index.rst
+++ b/browser/components/search/docs/index.rst
@@ -13,7 +13,7 @@ The search area covers:
 
 Search Engine handling is taken care of with the `toolkit Search Service`_.
 
-Most of the search code lives in `browser/components/search`_.
+Most of the search code lives in :searchfox:`browser/components/search`.
 
 .. toctree::
 
@@ -22,4 +22,3 @@ Most of the search code lives in `browser/components/search`_.
    telemetry
 
 .. _toolkit Search Service: /toolkit/search/index.html
-.. _browser/components/search: https://searchfox.org/firefox-main/source/browser/components/search
diff --git a/browser/components/search/docs/telemetry.rst b/browser/components/search/docs/telemetry.rst
index d3329745a861..211aed49bffb 100644
--- a/browser/components/search/docs/telemetry.rst
+++ b/browser/components/search/docs/telemetry.rst
@@ -212,5 +212,5 @@ browser.search.adclicks.*
 
 .. _additional telemetry of its own: /browser/urlbar/telemetry.html
 .. _SearchSERPTelemetry.sys.mjs and the associated parent/child actors: https://searchfox.org/mozilla-central/search?q=&path=SearchSERPTelemetry*.sys.mjs&case=false&regexp=false
-.. _BrowserSearchTelemetry: https://searchfox.org/firefox-main/source/browser/components/search/BrowserSearchTelemetry.sys.mjs
+.. _BrowserSearchTelemetry: :searchfox:`browser/components/search/BrowserSearchTelemetry.sys.mjs`
 .. _sap.counts Event documentation: https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/sap_counts
diff --git a/browser/components/touchbar/docs/index.rst b/browser/components/touchbar/docs/index.rst
index 090fbd8c7719..0e0f7573743e 100644
--- a/browser/components/touchbar/docs/index.rst
+++ b/browser/components/touchbar/docs/index.rst
@@ -53,7 +53,7 @@ JavaScript API
 
 ``browser/components/touchbar/MacTouchBar.sys.mjs`` defines what specific inputs are
 available to the user, what icon they will have, what action they will perform,
-and so on. Inputs are defined in the ``gBuiltInInputs`` object `in that file`_.
+and so on. Inputs are defined in the ``gBuiltInInputs`` object :searchfox:`in that file <mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02:browser/components/touchbar/MacTouchBar.sys.mjs#76>`.
 When creating a new object in ``gBuiltInInputs``, the available properties are
 documented in the JSDoc for ``TouchBarInput``:
 
@@ -98,8 +98,6 @@ Clarification on some of these properties is warranted.
   ``kInputTypes.POPOVER``, any input type except another ``kInputTypes.POPOVER``
   can be used.
 
-.. _in that file: https://searchfox.org/mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02/browser/components/touchbar/MacTouchBar.sys.mjs#76
-
 Input types
 -----------
 
@@ -238,12 +236,10 @@ will make the input available in the Touch Bar customization window (accessible
 from the Firefox menu bar item).
 
 If you want to to add your new input to the default set, add its identifier
-here_, where ``type`` is a value from ``kAllowedInputTypes`` in that
+:searchfox:`here <mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c:widget/cocoa/nsTouchBar.mm#100>`, where ``type`` is a value from ``kAllowedInputTypes`` in that
 file and ``key`` is the value you set for ``title`` in ``gBuiltInInputs``.
 You should request approval from UX before changing the default set of inputs.
 
-.. _here: https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/widget/cocoa/nsTouchBar.mm#100
-
 If you are interested in adding new features to Firefox's implementation of the
 Touch Bar API, read on!
 
@@ -259,7 +255,7 @@ The best resource to understand the Touch Bar API is Apple's
 these APIs and how one might extend ``nsTouchBar`` to enable new Touch Bar
 features.
 
-Every new Firefox window initializes ``nsTouchBar`` (link_). The function
+Every new Firefox window initializes ``nsTouchBar`` (:searchfox:`link <mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c:widget/cocoa/nsCocoaWindow.mm#2877>`). The function
 ``makeTouchBar`` is looked for automatically on every new instance of an
 ``NSWindow*``. If ``makeTouchBar`` is defined, that window will own a new
 instance of ``nsTouchBar``.
@@ -277,7 +273,6 @@ created containing a default set of inputs. ``initWithInputs`` can also take an
 initialized with only those inputs available.
 
 .. _official documentation: https://developer.apple.com/documentation/appkit/nstouchbar?language=objc
-.. _link: https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/widget/cocoa/nsCocoaWindow.mm#2877
 
 NSTouchBarItemIdentifiers
 -------------------------
@@ -304,7 +299,7 @@ If you need to generate an identifier, use the convenience method
 
 .. warning::
 
-  ``NSTouchBarItemIdentifier`` `is used in one other place`_: setting
+  ``NSTouchBarItemIdentifier`` :searchfox:`is used in one other place <mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c:widget/cocoa/nsTouchBar.mm#71>`: setting
   ``customizationIdentifier``. Do not ever change this string. If it is changed,
   any customizations users have made to the layout of their Touch Bar in Firefox
   will be erased.
@@ -316,8 +311,6 @@ which are the actual objects used by Apple's Touch Bar API and displayed in the
 Touch Bar. It is important to understand the difference between
 ``TouchBarInput`` and ``NSTouchBarItem``!
 
-.. _is used in one other place: https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/widget/cocoa/nsTouchBar.mm#71
-
 TouchBarInput creation flow
 ---------------------------
 Creating a Touch Bar and its ``TouchBarInputs`` flows as follows:
diff --git a/browser/components/urlbar/docs/dynamic-result-types.rst b/browser/components/urlbar/docs/dynamic-result-types.rst
index 48a6a11d229c..3bbe221b794c 100644
--- a/browser/components/urlbar/docs/dynamic-result-types.rst
+++ b/browser/components/urlbar/docs/dynamic-result-types.rst
@@ -178,9 +178,7 @@ for a description of this object.
 ~~~~~~~~~~~~~~~~~~~~
 
 If you are creating the provider in the internal address bar implementation in
-mozilla-central, then add styling to `dynamic-results.css`_.
-
-.. _dynamic-results.css: https://searchfox.org/firefox-main/source/browser/themes/shared/urlbar/dynamic-results.css
+mozilla-central, then add styling to :searchfox:`dynamic-results.css <browser/themes/shared/urlbar/dynamic-results.css>`.
 
 The rest of this section will discuss the CSS rules you need to use to style
 your results.
@@ -630,7 +628,5 @@ Appendix A: Examples
 This section lists some example and real-world consumers of dynamic result
 types.
 
-`Tab-to-Search Provider`__
+:searchfox:`Tab-to-Search Provider <browser/components/urlbar/UrlbarProviderTabToSearch.sys.mjs>`
   This is a built-in provider in mozilla-central that uses dynamic result types.
-
-__ https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarProviderTabToSearch.sys.mjs
diff --git a/browser/components/urlbar/docs/index.rst b/browser/components/urlbar/docs/index.rst
index 253a09e781ba..288d72f09a00 100644
--- a/browser/components/urlbar/docs/index.rst
+++ b/browser/components/urlbar/docs/index.rst
@@ -25,7 +25,7 @@ If you are interested in the technical details, you might want to skip ahead to
 Codebase
 --------
 
-The address bar code lives in `browser/components/urlbar <https://searchfox.org/firefox-main/source/browser/components/urlbar/>`_.
+The address bar code lives in :searchfox:`browser/components/urlbar <browser/components/urlbar/>`.
 
 Table of Contents
 -----------------
diff --git a/browser/components/urlbar/docs/lifetime.rst b/browser/components/urlbar/docs/lifetime.rst
index d8db4aa966e4..89b4bb72e96f 100644
--- a/browser/components/urlbar/docs/lifetime.rst
+++ b/browser/components/urlbar/docs/lifetime.rst
@@ -18,14 +18,14 @@ of April 2023.
 #.
    The user types a query (e.g. "coffee near me") into the *UrlbarInput*
    `<input> DOM element <https://searchfox.org/mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89/browser/base/content/navigator-toolbox.inc.xhtml#330-336>`_.
-   That DOM element `tells <https://searchfox.org/mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89/browser/components/urlbar/UrlbarInput.sys.mjs#3312>`_
+   That DOM element :searchfox:`tells <mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89:browser/components/urlbar/UrlbarInput.sys.mjs#3312>`
    *UrlbarInput* that text is being input.
 
 #.
-   *UrlbarInput* `starts a search <https://searchfox.org/mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89/browser/components/urlbar/UrlbarInput.sys.mjs#3395>`_.
-   It `creates <https://searchfox.org/mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89/browser/components/urlbar/UrlbarInput.sys.mjs#1549>`_
+   *UrlbarInput* :searchfox:`starts a search <mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89:browser/components/urlbar/UrlbarInput.sys.mjs#3395>`.
+   It :searchfox:`creates <mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89:browser/components/urlbar/UrlbarInput.sys.mjs#1549>`
    a `UrlbarQueryContext <https://firefox-source-docs.mozilla.org/browser/urlbar/overview.html#the-urlbarquerycontext>`_
-   and `passes it to UrlbarController <https://searchfox.org/mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89/browser/components/urlbar/UrlbarInput.sys.mjs#1548>`_.
+   and :searchfox:`passes it to UrlbarController <mozilla-central/rev/1f4f99a8f331cce8467a50742178b6d46914ab89:browser/components/urlbar/UrlbarInput.sys.mjs#1548>`.
    The query context is an object that will exist for the lifetime of the query
    and it's how we keep track of what results to show. It contains information
    like what kind of results are allowed, the search string ("coffee near me",
@@ -33,20 +33,20 @@ of April 2023.
    *UrlbarQueryContext* is created every time the text in the input changes.
 
 #.
-   *UrlbarController* `tells ProvidersManager <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarController.sys.mjs#140>`_
+   *UrlbarController* :searchfox:`tells ProvidersManager <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarController.sys.mjs#140>`
    that the providers should fetch results.
 
 #.
-   *ProvidersManager* tells `each <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#408>`_
+   *ProvidersManager* tells :searchfox:`each <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#408>`
    provider to decide if it wants to provide results for this query by calling
-   their `isActive <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#422>`_
+   their :searchfox:`isActive <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#422>`
    methods. The provider can decide whether or not it will be active for this
    query. Some providers are rarely active: for example,
-   *UrlbarProviderTopSites* `isn't active if the user has typed a search string <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProviderTopSites.sys.mjs#97>`_.
+   *UrlbarProviderTopSites* :searchfox:`isn't active if the user has typed a search string <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProviderTopSites.sys.mjs#97>`.
 
 #.
    *ProvidersManager* then tells the *active* providers to fetch results by
-   `calling their startQuery method <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#462>`_.
+   :searchfox:`calling their startQuery method <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#462>`.
 
 #.
    The providers fetch results for the query asynchronously. Each provider
@@ -57,9 +57,9 @@ of April 2023.
 
 #.
    The providers send their results back to *ProvidersManager*. They do
-   this one result at a time by `calling the addCallback callback <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProviderSearchSuggestions.sys.mjs#292>`_
+   this one result at a time by :searchfox:`calling the addCallback callback <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProviderSearchSuggestions.sys.mjs#292>`
    passed into startQuery. *ProvidersManager* takes all the results from all the
-   providers and `puts them into the list of unsorted results <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#607>`_.
+   providers and :searchfox:`puts them into the list of unsorted results <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#607>`.
 
    Due to the asynchronous and parallel nature of providers, this and the
    following steps may occur multiple times per search. Some providers may take
@@ -71,7 +71,7 @@ of April 2023.
    following steps.
 
 #.
-   *ProvidersManager* `asks <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#648>`_
+   *ProvidersManager* :searchfox:`asks <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#648>`
    *UrlbarMuxer* to sort the unsorted results.
 
 #.
@@ -83,15 +83,15 @@ of April 2023.
 
 #.
    Once the results are sorted, *ProvidersManager*
-   `tells UrlbarController <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#675>`_
+   :searchfox:`tells UrlbarController <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarProvidersManager.sys.mjs#675>`
    that results are ready to be shown.
 
 #.
-   *UrlbarController* `sends out a notification <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarController.sys.mjs#213>`_
-   that results are ready to be shown. *UrlbarView* was `listening <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarView.sys.mjs#662>`_
-   for that notification. Once the view gets the notification, it `calls #updateResults <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarView.sys.mjs#670>`_
-   to create `DOM nodes <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarView.sys.mjs#1185>`_
-   for each *UrlbarResult* and `inserts them <https://searchfox.org/mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172/browser/components/urlbar/UrlbarView.sys.mjs#1156>`_
+   *UrlbarController* :searchfox:`sends out a notification <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarController.sys.mjs#213>`
+   that results are ready to be shown. *UrlbarView* was :searchfox:`listening <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarView.sys.mjs#662>`
+   for that notification. Once the view gets the notification, it :searchfox:`calls #updateResults <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarView.sys.mjs#670>`
+   to create :searchfox:`DOM nodes <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarView.sys.mjs#1185>`
+   for each *UrlbarResult* and :searchfox:`inserts them <mozilla-central/rev/0ffaecaa075887ab07bf4c607c61ea2faa81b172:browser/components/urlbar/UrlbarView.sys.mjs#1156>`
    into the view's DOM element.
 
    As described above, we may reach this step multiple times per search. That
diff --git a/browser/components/urlbar/docs/nontechnical-overview.rst b/browser/components/urlbar/docs/nontechnical-overview.rst
index 1b6fdd98c9fb..e3ba1f6a0eef 100644
--- a/browser/components/urlbar/docs/nontechnical-overview.rst
+++ b/browser/components/urlbar/docs/nontechnical-overview.rst
@@ -485,7 +485,7 @@ Search Interventions
 
 Search interventions help the user perform a task based on their search string.
 There are three kinds of interventions, and each is triggered by typing a
-certain set of phrases_ in the input. They always appear as the second result,
+certain set of :searchfox:`phrases <mozilla-central/rev/c4d682be93f090e99d5f4049ceb7b6b6c03d0632:browser/components/urlbar/UrlbarProviderInterventions.jsm#64>` in the input. They always appear as the second result,
 after the heuristic result.
 
 The three kinds of interventions are:
@@ -518,8 +518,6 @@ Currently this feature is limited to English-speaking locales, but work is
 ongoing to build a more sophisticated intent-matching platform to support other
 locales, more complex search strings, and more kinds of interventions.
 
-.. _phrases: https://searchfox.org/mozilla-central/rev/c4d682be93f090e99d5f4049ceb7b6b6c03d0632/browser/components/urlbar/UrlbarProviderInterventions.jsm#64
-
 Search Tips
 ~~~~~~~~~~~
 
diff --git a/browser/components/urlbar/docs/overview.rst b/browser/components/urlbar/docs/overview.rst
index f04b1bb74078..74d9ed635226 100644
--- a/browser/components/urlbar/docs/overview.rst
+++ b/browser/components/urlbar/docs/overview.rst
@@ -72,7 +72,7 @@ The Model
 
 The *Model* is the component responsible for retrieving search results based on
 the user's input, and sorting them accordingly to their importance.
-At the core is the `ProvidersManager <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarProvidersManager.sys.mjs>`_,
+At the core is the :searchfox:`ProvidersManager <browser/components/urlbar/UrlbarProvidersManager.sys.mjs>`,
 a component tracking all the available search providers, and managing searches
 across them.
 
@@ -92,7 +92,7 @@ Queries can be canceled.
   terminating any running and future SQL query, unless a query is running inside
   a *runInCriticalSection* task.
 
-The *searchString* gets tokenized by the `UrlbarTokenizer <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarTokenizer.sys.mjs>`_
+The *searchString* gets tokenized by the :searchfox:`UrlbarTokenizer <browser/components/urlbar/UrlbarTokenizer.sys.mjs>`
 component into tokens, some of these tokens have a special meaning and can be
 used by the user to restrict the search to specific result type (See the
 *UrlbarTokenizer::TYPE* enum).
@@ -246,7 +246,7 @@ indicated by the UrlbarQueryContext.muxer property.
 The Controller
 --------------
 
-`UrlbarController <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarController.sys.mjs>`_
+:searchfox:`UrlbarController <browser/components/urlbar/UrlbarController.sys.mjs>`
 is the component responsible for reacting to user's input, by communicating
 proper course of action to the Model (e.g. starting/stopping a query) and the
 View (e.g. showing/hiding a panel). It is also responsible for reporting Telemetry.
@@ -279,7 +279,7 @@ user and handling their input.
   The View is a replaceable component, as such what is described here is a
   reference for the default View, but may not be valid for other implementations.
 
-`UrlbarInput.sys.mjs <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarInput.sys.mjs>`_
+:searchfox:`UrlbarInput.sys.mjs <browser/components/urlbar/UrlbarInput.sys.mjs>`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Implements an input box *View*, owns an *UrlbarView*.
@@ -323,7 +323,7 @@ Implements an input box *View*, owns an *UrlbarView*.
     value;
   }
 
-`UrlbarView.sys.mjs <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarView.sys.mjs>`_
+:searchfox:`UrlbarView.sys.mjs <browser/components/urlbar/UrlbarView.sys.mjs>`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Represents the base *View* implementation, communicates with the *Controller*.
@@ -353,7 +353,7 @@ Represents the base *View* implementation, communicates with the *Controller*.
 UrlbarResult
 ------------
 
-An `UrlbarResult <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarResult.sys.mjs>`_
+An :searchfox:`UrlbarResult <browser/components/urlbar/UrlbarResult.sys.mjs>`
 instance represents a single search result with a result type, that
 identifies specific kind of results.
 Each kind has its own properties, that the *View* may support, and a few common
diff --git a/browser/components/urlbar/docs/ranking-legacy.rst b/browser/components/urlbar/docs/ranking-legacy.rst
index cd6e7948d34a..c667be00655a 100644
--- a/browser/components/urlbar/docs/ranking-legacy.rst
+++ b/browser/components/urlbar/docs/ranking-legacy.rst
@@ -15,7 +15,7 @@ Before results appear in the UrlbarView, they are fetched from providers.
 Each `UrlbarProvider <https://firefox-source-docs.mozilla.org/browser/urlbar/overview.html#urlbarprovider>`_
 implements its own internal ranking and returns sorted results.
 
-Externally all the results are ranked by the `UrlbarMuxer <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`_
+Externally all the results are ranked by the :searchfox:`UrlbarMuxer <browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`
 according to a hardcoded list of groups and sub-groups.
 
 .. NOTE:: Preferences can influence the groups order, for example by putting
@@ -192,7 +192,7 @@ Frecency is recalculated:
   In this case, when a change influencing frecency happens, the ``recalc_frecency``
   database field for the page is set to ``1``.
 
-Recalculation is done by the `PlacesFrecencyRecalculator <https://searchfox.org/firefox-main/source/toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>`_ module.
+Recalculation is done by the :searchfox:`PlacesFrecencyRecalculator <toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>` module.
 The Recalculator is notified when ``PlacesUtils.history.shouldStartFrecencyRecalculation``
 value changes from false to true, that means there's values to recalculate.
 A DeferredTask is armed, that will look for a user idle opportunity
diff --git a/browser/components/urlbar/docs/ranking.rst b/browser/components/urlbar/docs/ranking.rst
index b7547a836229..2db28552be3f 100644
--- a/browser/components/urlbar/docs/ranking.rst
+++ b/browser/components/urlbar/docs/ranking.rst
@@ -7,7 +7,7 @@ Before results appear in the UrlbarView, they are fetched from providers.
 Each `UrlbarProvider <https://firefox-source-docs.mozilla.org/browser/urlbar/overview.html#urlbarprovider>`_
 implements its own internal ranking and returns sorted results.
 
-Externally all the results are ranked by the `UrlbarMuxer <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`_
+Externally all the results are ranked by the :searchfox:`UrlbarMuxer <browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`
 according to an hardcoded list of groups and sub-groups.
 
 .. NOTE:: Preferences can influence the groups order, for example by putting
@@ -220,7 +220,7 @@ Frecency is recalculated:
   In this case, when a change influencing frecency happens, the ``recalc_frecency``
   database field for the page is set to ``1``.
 
-Recalculation is done by the `PlacesFrecencyRecalculator <https://searchfox.org/firefox-main/source/toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>`_ module.
+Recalculation is done by the :searchfox:`PlacesFrecencyRecalculator <toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>` module.
 The Recalculator is notified when ``PlacesUtils.history.shouldStartFrecencyRecalculation``
 value changes from false to true, that means there's values to recalculate.
 A DeferredTask is armed, that will look for a user idle opportunity
diff --git a/browser/components/urlbar/docs/telemetry.rst b/browser/components/urlbar/docs/telemetry.rst
index 591e1c5941d8..c4b6a484368e 100644
--- a/browser/components/urlbar/docs/telemetry.rst
+++ b/browser/components/urlbar/docs/telemetry.rst
@@ -90,7 +90,7 @@ PLACES_FRECENCY_RECALC_CHUNK_TIME_MS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
   This records the time necessary to recalculate frecency of a chunk of pages,
-  as defined in the `PlacesFrecencyRecalculator <https://searchfox.org/firefox-main/source/toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>`_ module.
+  as defined in the :searchfox:`PlacesFrecencyRecalculator <toolkit/components/places/PlacesFrecencyRecalculator.sys.mjs>` module.
 
 Scalars
 -------
diff --git a/browser/components/urlbar/docs/testing.rst b/browser/components/urlbar/docs/testing.rst
index 8f354628bbd0..4974b942ffba 100644
--- a/browser/components/urlbar/docs/testing.rst
+++ b/browser/components/urlbar/docs/testing.rst
@@ -38,11 +38,9 @@ connect it to other components in another language, such as JavaScript.
 Each XPCShell test is executed in a new shell instance, therefore you will
 see several Firefox icons pop up and close when XPCShell tests are executing.
 These are two examples of XPCShell tests for the address bar
-`test_providerHeuristicFallback <https://searchfox.org/firefox-main/source
-/browser/components/urlbar/tests/unit/test_providerHeuristicFallback.js>`_
+:searchfox:`test_providerHeuristicFallback <browser/components/urlbar/tests/unit/test_providerHeuristicFallback.js>`
 and
-`test_providerTabToSearch <https://searchfox.org/firefox-main/source/browser
-/components/urlbar/tests/unit/test_providerTabToSearch.js>`_.
+:searchfox:`test_providerTabToSearch <browser/components/urlbar/tests/unit/test_providerTabToSearch.js>`.
 
 When To Write a XPCShell or Mochitest?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -54,11 +52,9 @@ testing a specific component in the UI.
 If you are writing a test for a urlbarProvider, you can test the Provider
 through a XPCShell test. Providers do not modify the UI, instead what they do is
 receive a url string query, search for the string and bring back the result. An
-example is the `ProviderPlaces <https://searchfox.org/mozilla-central/sou
-rce/browser/components/urlbar/UrlbarProviderPlaces.sys.mjs>`_, which fetches
+example is the :searchfox:`ProviderPlaces <browser/components/urlbar/UrlbarProviderPlaces.sys.mjs>`, which fetches
 results from the Places database. Another component that’s good for writing
-XPCShell test is the `urlbarMuxer <https://searchfox.org/mozilla-central/
-source/browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`_.
+XPCShell test is the :searchfox:`urlbarMuxer <browser/components/urlbar/UrlbarMuxerStandard.sys.mjs>`.
 
 There may be times where writing both an XPCShell test and browser test is
 necessary. In these situations, you could be testing the result from a Provider
@@ -107,8 +103,7 @@ manifest in alphabetical order.
 
 Start in the manifest file and add your test name in alphabetical
 order. The manifest file we should add our test in is
-`browser.toml <https://searchfox.org/firefox-main/source/browser/components/
-urlbar/tests/browser/browser.toml>`_. The ``urlbar/test/browser/`` directory
+:searchfox:`browser.toml <browser/components/urlbar/tests/browser/browser.toml>`. The ``urlbar/test/browser/`` directory
 is the main browser test directory for address bar, and the manifest file
 linked above is the main browser test manifest.
 
@@ -145,8 +140,7 @@ ensures what is done within one test will not affect subsequent tests.
 
 head.js and common-head.js
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
-The `head.js <https://searchfox.org/firefox-main/source/browser/components
-/urlbar/tests/browser/head.js>`_ file is executed at the beginning before each
+The :searchfox:`head.js <browser/components/urlbar/tests/browser/head.js>` file is executed at the beginning before each
 test and contains imports to modules which are useful for each test.
 Any tasks ``head.js`` adds (via add_task) will run first for each test, and
 any variables and functions it defines will be available in the scope of
@@ -158,7 +152,7 @@ modules names to where they can be found, their paths. ``Lazy`` means the files
 are only imported if or when it is used. Any tests in this directory can use
 these modules without importing it themselves in their own file.
 The ``head.js`` provides a convenience for this purpose. The ``head.js`` file
-imports `common-head.js <https://searchfox.org/firefox-main/source/browser/components/urlbar/tests/browser/head-common.js>`_
+imports :searchfox:`common-head.js <browser/components/urlbar/tests/browser/head-common.js>`
 making everything within ``head-common.js`` available in ``head.js`` as well.
 
 The ``registerCleanupFunction`` is an important function in browser mochi tests
@@ -176,7 +170,7 @@ test.
 
 UrlbarTestUtils
 ~~~~~~~~~~~~~~~
-`UrlbarTestUtils.sys.mjs <https://searchfox.org/firefox-main/source/browser/components/urlbar/tests/UrlbarTestUtils.sys.mjs>`_ is useful for url bar testing. This
+:searchfox:`UrlbarTestUtils.sys.mjs <browser/components/urlbar/tests/UrlbarTestUtils.sys.mjs>` is useful for url bar testing. This
 file contains methods that can help with starting a new search in the url bar,
 waiting for a new search to complete, returning the results in
 the view, and etc.
@@ -202,8 +196,7 @@ bookmarks, waiting for notification of visited pages, and etc.
 
 EventUtils
 ~~~~~~~~~~
-`EventUtils.js <https://searchfox.org/firefox-main/source/testing/mochitest
-/tests/SimpleTest/EventUtils.js>`_ is an older test file and does not
+:searchfox:`EventUtils.js <testing/mochitest/tests/SimpleTest/EventUtils.js>` is an older test file and does not
 need to be imported because it is not a ``.sys.mjs`` file. ``EventUtils`` is only
 used for browser tests, unlike the other TestUtils listed above which are
 used for browser tests, XPCShell tests and other tests.
diff --git a/browser/components/urlbar/docs/utilities.rst b/browser/components/urlbar/docs/utilities.rst
index 9dee00091f83..bc4313a34470 100644
--- a/browser/components/urlbar/docs/utilities.rst
+++ b/browser/components/urlbar/docs/utilities.rst
@@ -3,7 +3,7 @@ Utilities
 
 Various modules provide shared utilities to the other components:
 
-`UrlbarPrefs.sys.mjs <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarPrefs.sys.mjs>`_
+:searchfox:`UrlbarPrefs.sys.mjs <browser/components/urlbar/UrlbarPrefs.sys.mjs>`
 -------------------------------------------------------------------------------------------------------------------
 
 Implements a Map-like storage or urlbar related preferences. The values are kept
@@ -19,7 +19,7 @@ up-to-date.
 
   Newly added preferences should always be properly documented in UrlbarPrefs.
 
-`UrlbarUtils.sys.mjs <https://searchfox.org/firefox-main/source/browser/components/urlbar/UrlbarUtils.sys.mjs>`_
+:searchfox:`UrlbarUtils.sys.mjs <browser/components/urlbar/UrlbarUtils.sys.mjs>`
 -------------------------------------------------------------------------------------------------------------------
 
 Includes shared utils and constants shared across all the components.
diff --git a/browser/docs/BrowserUsageTelemetry.rst b/browser/docs/BrowserUsageTelemetry.rst
index e240f52131ef..24c931aaccb0 100644
--- a/browser/docs/BrowserUsageTelemetry.rst
+++ b/browser/docs/BrowserUsageTelemetry.rst
@@ -4,7 +4,7 @@
 Browser Usage Telemetry
 =======================
 
-The `BrowserUsageTelemetry.sys.mjs <https://searchfox.org/firefox-main/source/browser/modules/BrowserUsageTelemetry.sys.mjs>`_ module is the main module for measurements regarding the browser usage (e.g. tab and window counts, search counts, ...).
+The :searchfox:`BrowserUsageTelemetry.sys.mjs <browser/modules/BrowserUsageTelemetry.sys.mjs>` module is the main module for measurements regarding the browser usage (e.g. tab and window counts, search counts, ...).
 
 The measurements recording begins right after the ``SessionStore`` has finished restoring the session (i.e. restoring tabs/windows after Firefox starts).
 
@@ -17,7 +17,7 @@ The usage telemetry module currently measures these interactions with the browse
 - *navigation events*: at this time, this only counts the number of time a page load is triggered by a particular UI interaction (e.g. by searching through the URL bar, see ``browser.engagement.navigation.urlbar``).
 
 
-Please see `Scalars.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Scalars.yaml>`_ for the full list of tracked interactions.
+Please see :searchfox:`Scalars.yaml <toolkit/components/telemetry/Scalars.yaml>` for the full list of tracked interactions.
 
 Customizable UI
 ===============
diff --git a/browser/docs/CommandLineParameters.rst b/browser/docs/CommandLineParameters.rst
index 5ba4e6df8d0e..34dd946d3a0c 100644
--- a/browser/docs/CommandLineParameters.rst
+++ b/browser/docs/CommandLineParameters.rst
@@ -19,8 +19,7 @@ Known parameters
        that the command line is untrusted and must be sanitized.  Command lines
        with ``-osint`` are rejected unless they have a very specific structure,
        usually ``firefox.exe -osint -url URL`` or ``firefox.exe -osint
-       -private-window URL``: refer to `the EnsureCommandLineSafe function
-       <https://searchfox.org/mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9/toolkit/xre/CmdLineAndEnvUtils.h#196>`_.
+       -private-window URL``: refer to :searchfox:`the EnsureCommandLineSafe function <mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9:toolkit/xre/CmdLineAndEnvUtils.h#196>`.
        These command lines are produced by apps delegating to Firefox, and the
        resulting URL may not be correctly quoted.  The sanitization process
        ensures that maliciously chosen URLs do not add additional parameters to
diff --git a/browser/extensions/formautofill/docs/index.rst b/browser/extensions/formautofill/docs/index.rst
index abdb317de96b..33e70caa2905 100644
--- a/browser/extensions/formautofill/docs/index.rst
+++ b/browser/extensions/formautofill/docs/index.rst
@@ -10,7 +10,7 @@ Our objective is to increase user engagement, satisfaction and retention for fre
 
 Form Autofill handles filling in addresses and credit cards into forms. While the filling aspect of this is straightforward and uses the same mechanism as other autocomplete types, much of the additional work involves analyzing and classifying the form to determine which form field corresponds to which type of data. For instance, text boxes are classified into different types of address data.
 
-For historical reasons, part of the form autofill is implemented using an extension, located in `browser/extensions/formautofill <https://searchfox.org/firefox-main/source/browser/extensions/formautofill>`_. It is this extension which adds the form autofill actors used to handle the search for possible results. However, most of the work is done via code in `toolkit/components/formautofill <https://searchfox.org/firefox-main/source/toolkit/components/formautofill>`_.
+For historical reasons, part of the form autofill is implemented using an extension, located in :searchfox:`browser/extensions/formautofill`. It is this extension which adds the form autofill actors used to handle the search for possible results. However, most of the work is done via code in :searchfox:`toolkit/components/formautofill`.
 
 Form Autofill uses the autocomplete popup mechanism to show a list of suggestions to the user based on what they have typed so far. The user can also press the cursor key or tab key to open the autocomplete popup while the focus is within a field.
 
@@ -20,7 +20,7 @@ For more information about autocomplete, see :doc:`Autocomplete </toolkit/compon
 How Form Autofill Works
 -----------------------
 
-The form fill actor ``FormAutofillChild`` waits for form fields to be focused. When a field is focused, it starts the process of analyzing the form and picking out which fields might be address or credit card related. This process is primarily done by the ``getFormInfo`` function within `FormAutofillHeuristics.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/FormAutofillHeuristics.sys.mjs>`_. This process is separate from the mechanism used to trigger an autocomplete popup.
+The form fill actor ``FormAutofillChild`` waits for form fields to be focused. When a field is focused, it starts the process of analyzing the form and picking out which fields might be address or credit card related. This process is primarily done by the ``getFormInfo`` function within :searchfox:`FormAutofillHeuristics.sys.mjs <toolkit/components/formautofill/shared/FormAutofillHeuristics.sys.mjs>`. This process is separate from the mechanism used to trigger an autocomplete popup.
 
 Form Autofill can handle filling in <input>, <textarea> and <select> elements.
 
@@ -28,19 +28,19 @@ There are three mechanisms that can be used to identify a field:
 
 1. **autocomplete attributes**: authors may place an autocomplete attribute on a form field to identify its purpose. This is most likely to be correct although sometimes authoring errors will occur and we attempt to fix some common cases.
 2. **fathom**: Fathom is a simple learning system that uses a selection of rules to identify credit card related fields. It currently is used to detect the credit card name and number fields (``cc-name`` and ``cc-number``) but does not detect other credit card fields or operate on address fields.
-3. **regular expressions**: a large list of regular expressions located in `HeuristicsRegExp.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/HeuristicsRegExp.sys.mjs>`_ that is used to match the ids, names, placeholders and labels associated with form elements. This is where most of the analysis of form fields is done for addresses.
+3. **regular expressions**: a large list of regular expressions located in :searchfox:`HeuristicsRegExp.sys.mjs <toolkit/components/formautofill/shared/HeuristicsRegExp.sys.mjs>` that is used to match the ids, names, placeholders and labels associated with form elements. This is where most of the analysis of form fields is done for addresses.
 
 The ``element.getAutocompleteInfo()`` function provides the parsed result of ``autocomplete`` attribute which includes the field name and section information defined in `autofill spec <https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill>`_
 
 Each field in a form is classified into a number of different field types, for example: ``email``, ``address-line1``, ``country`` and so on. Many fields will not be able to be placed into a definite type, and many forms will have multiple fields classified with the same type. Work is ongoing to reduce the number of errors made in classifying fields.
 
-After fields are classified, some additional heuristics are run (within the ``parseAndUpdateFieldNamesParent`` function in `FormAutofillHeuristics.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/FormAutofillHeuristics.sys.mjs>`_). These are responsible for further checking for common field classification issues. For example, when multiple address line fields appear in a row, it is likely that they represent a separate line of the address (street, apartment number, building, etc) and appear in order. Another example is that it is common on Japanese web sites to have a separate set of name fields to indicate the pronounciation of one's name; heuristics are included to recognize this situation.
+After fields are classified, some additional heuristics are run (within the ``parseAndUpdateFieldNamesParent`` function in :searchfox:`FormAutofillHeuristics.sys.mjs <toolkit/components/formautofill/shared/FormAutofillHeuristics.sys.mjs>`). These are responsible for further checking for common field classification issues. For example, when multiple address line fields appear in a row, it is likely that they represent a separate line of the address (street, apartment number, building, etc) and appear in order. Another example is that it is common on Japanese web sites to have a separate set of name fields to indicate the pronounciation of one's name; heuristics are included to recognize this situation.
 
 Note that the heuristics within ``parseAndUpdateFieldNamesParent`` are done within the parent browser process so no longer have access to the form fields directly, so any information needed will need to be stored in the field data (usually called ``fieldDetails`` within the code).
 
 However, there are a few heuristics in ``parseAndUpdateFieldNamesContent`` that are done in the web page process beforehand. Most processing happens in the parent process afterwards because all of the form fields across different subframes (iframes) can be searched and collected together as a single form. There are a number of web sites that break up each field into separate child iframes.
 
-Once fields have been identified, they are split into sections. Some sites will have multiple sections for addresses, one for a billing address and one for a shipping address. This handling is done by groupFields within `FormAutofillSection.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/FormAutofillSection.sys.mjs>`_. The ``autocomplete`` attribute may be used on a field in a web page to be explicit about which section to use for that field, but otherwise the heuristics try to determine this automatically.
+Once fields have been identified, they are split into sections. Some sites will have multiple sections for addresses, one for a billing address and one for a shipping address. This handling is done by groupFields within :searchfox:`FormAutofillSection.sys.mjs <toolkit/components/formautofill/shared/FormAutofillSection.sys.mjs>`. The ``autocomplete`` attribute may be used on a field in a web page to be explicit about which section to use for that field, but otherwise the heuristics try to determine this automatically.
 
 Once the fields are identified, a message is sent back to the child process so that ``markAsAutoCompletableField()`` may be called on each detected field, allowing the autocomplete actor to recognize that the form fill actor is able to provide results for that form field. In addition, the section and form field details are saved in the field ``sectionsByRootId`` within ``FormAutofillParent`` to that they may be retreived when the autocomplete is performed.
 
@@ -56,17 +56,17 @@ Additional Cases
 Country Meta Data
 -----------------
 
-The specifics for each region is defined in the file `AddressMetaData.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/AddressMetaData.sys.mjs>`_. This file contains information about the regions in each country, postal code formats, languages used in each region and so forth. This file contains links to documentation about the format of this data and is a good place to look for information that might be country specific. For example, when we look at data for Brazil, we can see a list of states (federative units), and also see that Brazil has defined a "sublocality_name_type" field which indicates a third level of region besides state and city, used for the neighborhood. The neighborhood appears in the address preference dialog when adding Brazilian addresses and can be autofilled as needed. Most other regions do not include a neighborhood field.
+The specifics for each region is defined in the file :searchfox:`AddressMetaData.sys.mjs <toolkit/components/formautofill/shared/AddressMetaData.sys.mjs>`. This file contains information about the regions in each country, postal code formats, languages used in each region and so forth. This file contains links to documentation about the format of this data and is a good place to look for information that might be country specific. For example, when we look at data for Brazil, we can see a list of states (federative units), and also see that Brazil has defined a "sublocality_name_type" field which indicates a third level of region besides state and city, used for the neighborhood. The neighborhood appears in the address preference dialog when adding Brazilian addresses and can be autofilled as needed. Most other regions do not include a neighborhood field.
 
 Form Submission
 -----------------
 
-When a form is submitted, a prompt may be show asking the user if they wish to save the address or credit card information. This helps the user realize that the autofill capability is available. The filled in data on the form can optionally be automatically saved as a new address or credit card. This is done within the ``onFormSubmit`` function of `FormAutofillParent <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/FormAutofillParent.sys.mjs>`_.
+When a form is submitted, a prompt may be show asking the user if they wish to save the address or credit card information. This helps the user realize that the autofill capability is available. The filled in data on the form can optionally be automatically saved as a new address or credit card. This is done within the ``onFormSubmit`` function of :searchfox:`FormAutofillParent <toolkit/components/formautofill/FormAutofillParent.sys.mjs>`.
 
-In general, however, we do not show the prompt to save a new address or credit card if the user has not filled in enough fields, fillin is disabled in the user's region, or the form does not contain the right fields. Which fields are necessary is dependent on the region. For example, typically, a street, city and postal code is required. The specific data needed to save the form data is determined from the `AddressMetaData.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/AddressMetaData.sys.mjs>`_ as described above.
+In general, however, we do not show the prompt to save a new address or credit card if the user has not filled in enough fields, fillin is disabled in the user's region, or the form does not contain the right fields. Which fields are necessary is dependent on the region. For example, typically, a street, city and postal code is required. The specific data needed to save the form data is determined from the :searchfox:`AddressMetaData.sys.mjs <toolkit/components/formautofill/shared/AddressMetaData.sys.mjs>` as described above.
 
 If an address is determined to be the same as an existing saved address, the prompt does not appear. Some heuristics within
-`AddressParser.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/shared/AddressParser.sys.mjs>`_ are used to determine if the address is the same as an existing saved address, because this can be inexact matching, for example, 'Floor 2' and '2nd floor' are different strings but refer to the same thing. This ensures that the amount of times the user is prompted is reduced when the address is similar.
+:searchfox:`AddressParser.sys.mjs <toolkit/components/formautofill/shared/AddressParser.sys.mjs>` are used to determine if the address is the same as an existing saved address, because this can be inexact matching, for example, 'Floor 2' and '2nd floor' are different strings but refer to the same thing. This ensures that the amount of times the user is prompted is reduced when the address is similar.
 
 Report Issues
 -------------
diff --git a/browser/installer/windows/docs/FullInstaller.rst b/browser/installer/windows/docs/FullInstaller.rst
index 576ec8e6c253..fe57fb97c85d 100644
--- a/browser/installer/windows/docs/FullInstaller.rst
+++ b/browser/installer/windows/docs/FullInstaller.rst
@@ -4,11 +4,11 @@ Full Installer
 
 The full installer is actually responsible for installing the browser; it's what the stub launches in order to do the "real" installing work, but it's also available separately. It uses a traditional "wizard" interface design, as is (somewhat) natively supported by NSIS. It can also be :doc:`configured <FullConfig>` to launch in a silent mode, suitable for scripting or managed deployments.
 
-The full installer's main script is `installer.nsi <https://searchfox.org/firefox-main/source/browser/installer/windows/nsis/installer.nsi>`_, but most of the heavy lifting is done by the shared functions in `common.nsh <https://searchfox.org/firefox-main/source/toolkit/mozapps/installer/windows/nsis/common.nsh>`_.
+The full installer's main script is :searchfox:`installer.nsi <browser/installer/windows/nsis/installer.nsi>`, but most of the heavy lifting is done by the shared functions in :searchfox:`common.nsh <toolkit/mozapps/installer/windows/nsis/common.nsh>`.
 
 If it was not launched by the :doc:`StubInstaller`, an :ref:`Install Ping` is sent when the installer exits.
 
-The installer writes ``installation_telemetry.json`` to the install location, this is read by Firefox in order to send a telemetry event, see the event definition in `Events.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Events.yaml>`_ (category ``installation``, event name ``first_seen``) for a description of the properties. There is also an ``install_timestamp`` property, which is saved in the profile to determine whether there has been a new installation; this is not sent as part of the ping.
+The installer writes ``installation_telemetry.json`` to the install location, this is read by Firefox in order to send a telemetry event, see the event definition in :searchfox:`Events.yaml <toolkit/components/telemetry/Events.yaml>` (category ``installation``, event name ``first_seen``) for a description of the properties. There is also an ``install_timestamp`` property, which is saved in the profile to determine whether there has been a new installation; this is not sent as part of the ping.
 
 The full installer can also access NSIS plugins written in C++, see :doc:`building NSIS plugins <NSISPlugins>` for more information.
 
diff --git a/browser/installer/windows/docs/Helper.rst b/browser/installer/windows/docs/Helper.rst
index 76833e934956..6029fc6b12f1 100644
--- a/browser/installer/windows/docs/Helper.rst
+++ b/browser/installer/windows/docs/Helper.rst
@@ -1,7 +1,7 @@
 ======
 Helper
 ======
-helper.exe contains the uninstaller, plus a routine that's run by the application updater after it applies an update, as well as a few utilities used for default browser handling and shortcut maintenance. It mainly consists of two files, uninstaller.nsi_, which is the main script and contains the entry point and the uninstall logic, and shared.nsh_, which contains most of the logic for the other functions.
+helper.exe contains the uninstaller, plus a routine that's run by the application updater after it applies an update, as well as a few utilities used for default browser handling and shortcut maintenance. It mainly consists of two files, :searchfox:`uninstaller.nsi <browser/installer/windows/nsis/uninstaller.nsi>`, which is the main script and contains the entry point and the uninstall logic, and :searchfox:`shared.nsh <browser/installer/windows/nsis/shared.nsh>`, which contains most of the logic for the other functions.
 
 Uninstaller
 -----------
@@ -33,7 +33,3 @@ Windows versions older than 10 contain a control panel called Set Program Access
 The helper also implements the ``/SetAsDefaultAppUser`` switch, which is invoked by the "Make Default" button in the Firefox preferences UI.
 
 On Windows 10 neither SetAsDefaultAppUser nor SetAsDefaultAppGlobal is effective because the default programs settings can only be modified by the Windows settings app. However they do still write the registry entries that are needed to get us an entry in the system default browser menu, should those entries not already exist (the installer always creates them, but running Firefox without having run the installer is supported). ShowShortcuts and HideShortcuts are never called on Windows 10 because the SPAD control panel no longer exists.
-
-
-.. _uninstaller.nsi: https://searchfox.org/firefox-main/source/browser/installer/windows/nsis/uninstaller.nsi
-.. _shared.nsh: https://searchfox.org/firefox-main/source/browser/installer/windows/nsis/shared.nsh
diff --git a/browser/installer/windows/docs/InstallerBuild.rst b/browser/installer/windows/docs/InstallerBuild.rst
index 6c6386c37238..09d8308075ef 100644
--- a/browser/installer/windows/docs/InstallerBuild.rst
+++ b/browser/installer/windows/docs/InstallerBuild.rst
@@ -38,7 +38,7 @@ Build process
 
 Both the full and stub installers are built through a similar process, which is summarized here along with references to the relevant bits of code.
 
-Most of this procedure is done in `makensis.mk <https://searchfox.org/firefox-main/source/toolkit/mozapps/installer/windows/nsis/makensis.mk>`_ and in the `mach repackage <https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/python/mozbuild/mozbuild/mach_commands.py#2166>`_ command.
+Most of this procedure is done in :searchfox:`makensis.mk <toolkit/mozapps/installer/windows/nsis/makensis.mk>` and in the :searchfox:`mach repackage <mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc:python/mozbuild/mozbuild/mach_commands.py#2166>` command.
 
 0. A prerequisite is for the application to be in a packaged state, so ``mach package`` first creates a release-style package and puts it in ``$OBJDIR/dist/firefox``.
 1. All required files are copied into the instgen directory. This includes .nsi and .nsh script files, plugin DLL files, image and icon files, and the 7-zip SFX module and its configuration files.
diff --git a/browser/installer/windows/docs/MSI.rst b/browser/installer/windows/docs/MSI.rst
index 3ffce9f7a55b..3d1088650efd 100644
--- a/browser/installer/windows/docs/MSI.rst
+++ b/browser/installer/windows/docs/MSI.rst
@@ -6,4 +6,4 @@ We provide a `Windows Installer <https://wikipedia.org/wiki/Windows_Installer>`_
 
 Our MSI packages are not "true" Windows Installer packages; they don't actually contain any installable components and don't register any product. They simply wrap the :doc:`full installer <FullInstaller>`, which performs the installation just as if it had been run normally. The main reason for this is the difficulty of adapting Firefox's existing update mechanisms to fit the way that Windows Installer would expect things to be done.
 
-The MSI package is built for every release along with the other package formats using the command ``./mach repackage msi``. That command invokes the `WiX tools <https://wixtoolset.org/>`_ to build the package from `a normal WiX XML file <https://searchfox.org/firefox-main/source/browser/installer/windows/msi/installer.wxs>`_, after filling in a few variables to customize the package for that particular Firefox build. The majority of the WiX file is concerned with passing parameters through from MSI properties to command-line arguments for the full installer to use; the rest is boilerplate to satisfy the minimum requirements for something that WiX will build and the Windows Installer system will load and run without errors.
+The MSI package is built for every release along with the other package formats using the command ``./mach repackage msi``. That command invokes the `WiX tools <https://wixtoolset.org/>`_ to build the package from :searchfox:`a normal WiX XML file <browser/installer/windows/msi/installer.wxs>`, after filling in a few variables to customize the package for that particular Firefox build. The majority of the WiX file is concerned with passing parameters through from MSI properties to command-line arguments for the full installer to use; the rest is boilerplate to satisfy the minimum requirements for something that WiX will build and the Windows Installer system will load and run without errors.
diff --git a/browser/installer/windows/docs/StubArch.rst b/browser/installer/windows/docs/StubArch.rst
index 189e66efc96b..b2601b4bf078 100644
--- a/browser/installer/windows/docs/StubArch.rst
+++ b/browser/installer/windows/docs/StubArch.rst
@@ -4,7 +4,7 @@ Stub Installer Architecture
 
 The stub is called a stub because it doesn't actually install anything. It's just a GUI frontend that downloads and runs the full installer in silent mode. The exact full installer that will be downloaded isn't baked into the stub; the channel and the locale (which are baked in) are sent in a request to the Bouncer service, which uses that information to redirect to the URL of the specific full installer file.
 
-The main stub installer source code file is `stub.nsi <https://searchfox.org/firefox-main/source/browser/installer/windows/nsis/stub.nsi>`_. Even though the stub installer doesn't install anything, it's still built on NSIS. This means the structure of stub.nsi is a bit odd for an NSIS script. There's only one section, and it's empty, and there are no predefined pages used. The work is all done in two custom pages, createProfileCleanup and createInstall, and the functions called by those two pages. Also, the stub's dialogs are built using HTML and the Windows WebBrowser control (based on Internet Explorer); see :doc:`this page <StubGUI>` for details about that.
+The main stub installer source code file is :searchfox:`stub.nsi <browser/installer/windows/nsis/stub.nsi>`. Even though the stub installer doesn't install anything, it's still built on NSIS. This means the structure of stub.nsi is a bit odd for an NSIS script. There's only one section, and it's empty, and there are no predefined pages used. The work is all done in two custom pages, createProfileCleanup and createInstall, and the functions called by those two pages. Also, the stub's dialogs are built using HTML and the Windows WebBrowser control (based on Internet Explorer); see :doc:`this page <StubGUI>` for details about that.
 
 The basic execution flow is this:
 
diff --git a/build/docs/flatpak.rst b/build/docs/flatpak.rst
index d6c77495e3c4..4fd7aa13763c 100644
--- a/build/docs/flatpak.rst
+++ b/build/docs/flatpak.rst
@@ -9,7 +9,7 @@ This page explains interactions between Firefox and Flatpak packaging format.
 Where is the upstream
 =====================
 
-The code reference itself is mozilla-central and the repackaging is under `the mach repackage flatpak command <https://searchfox.org/firefox-main/source/python/mozbuild/mozbuild/repackaging/flatpak.py>`_.
+The code reference itself is mozilla-central and the repackaging is under :searchfox:`the mach repackage flatpak command <python/mozbuild/mozbuild/repackaging/flatpak.py>`.
 
 Where to report bugs
 ====================
diff --git a/build/docs/jar-manifests.rst b/build/docs/jar-manifests.rst
index c52f04189825..6bd6ec6d40b0 100644
--- a/build/docs/jar-manifests.rst
+++ b/build/docs/jar-manifests.rst
@@ -19,8 +19,8 @@ The format of a jar.mn is fairly simple; it consists of a heading specifying
 which JAR file is being packaged, followed by indented lines listing files and
 chrome registration instructions.
 
-For a simple ``jar.mn`` file, see `toolkit/profile/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/toolkit/profile/jar.mn>`_. For a much
-more complex ``jar.mn`` file, see `toolkit/locales/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/toolkit/locales/jar.mn>`_. More examples with specific formats and uses are available below.
+For a simple ``jar.mn`` file, see :searchfox:`toolkit/profile/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:toolkit/profile/jar.mn>`. For a much
+more complex ``jar.mn`` file, see :searchfox:`toolkit/locales/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:toolkit/locales/jar.mn>`. More examples with specific formats and uses are available below.
 
 Shipping Chrome Files
 ======================
@@ -36,7 +36,7 @@ Note that file path mappings are listed by destination (left) followed by source
 Same Directory Omission
 ^^^^^^^^^^^^^^^^^^^^^^^
 If the JAR manifest and packaged files live in the same directory, the source path and parentheses can be omitted.
-A sample of a ``jar.mn`` file with omitted source paths and parentheses is `this revision of browser/components/colorways/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/browser/components/colorways/jar.mn>`_::
+A sample of a ``jar.mn`` file with omitted source paths and parentheses is :searchfox:`this revision of browser/components/colorways/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:browser/components/colorways/jar.mn>`::
 
    browser.jar:
      content/browser/colorwaycloset.html
@@ -51,13 +51,13 @@ Writing the following is equivalent, given that the aforementioned files exist i
      content/browser/colorwaycloset.js   (colorwaycloset.js)
 
 This manifest is responsible for packaging files needed by Colorway Closet, including
-JS scripts, localization files, images (ex. PNGs, AVIFs), and CSS styling. Look at `browser/components/colorways/colorwaycloset.html <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/browser/components/colorways/colorwaycloset.html#18>`_
+JS scripts, localization files, images (ex. PNGs, AVIFs), and CSS styling. Look at :searchfox:`browser/components/colorways/colorwaycloset.html <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:browser/components/colorways/colorwaycloset.html#18>`
 to see how a file may be referenced using its chrome URL.
 
 Absolute Paths
 ^^^^^^^^^^^^^^
 The source tree location may also be an absolute path (taken from the top of the source tree).
-One such example can be found in `toolkit/components/pictureinpicture/jar.mn <https://searchfox.org/mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b/toolkit/components/pictureinpicture/jar.mn>`_::
+One such example can be found in :searchfox:`toolkit/components/pictureinpicture/jar.mn <mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b:toolkit/components/pictureinpicture/jar.mn>`::
 
    toolkit.jar:
      * content/global/pictureinpicture/player.xhtml   (content/player.xhtml)
@@ -66,7 +66,7 @@ One such example can be found in `toolkit/components/pictureinpicture/jar.mn <ht
 Asterisk Marker (Preprocessing)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 An asterisk marker (``*``) at the beginning of the line indicates that the file should be processed by the :ref:`preprocessor` before being packaged.
-The file `toolkit/profile/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/toolkit/profile/jar.mn>`_ indicates that the file `toolkit/profile/content/profileDowngrade.xhtml <https://searchfox.org/mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b/toolkit/profile/content/profileDowngrade.xhtml#34,36>`_ should be
+The file :searchfox:`toolkit/profile/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:toolkit/profile/jar.mn>` indicates that the file :searchfox:`toolkit/profile/content/profileDowngrade.xhtml <mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b:toolkit/profile/content/profileDowngrade.xhtml#34,36>` should be
 run through the preprocessor, since it contains ``#ifdef`` and ``#endif`` statements that need to be interpreted::
 
    * content/mozapps/profile/profileDowngrade.xhtml  (content/profileDowngrade.xhtml)
@@ -74,8 +74,8 @@ run through the preprocessor, since it contains ``#ifdef`` and ``#endif`` statem
 Base Path, Variables, Wildcards and Localized Files
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The ``.jar`` file location may be preceded with a base path between square brackets.
-The file `toolkit/locales/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/toolkit/locales/jar.mn>`_ uses a base path so that the ``.jar`` file is under a ``localization`` directory,
-which is a `special directory parsed by mozbuild <https://searchfox.org/mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b/python/mozbuild/mozpack/packager/l10n.py#260-265>`_.
+The file :searchfox:`toolkit/locales/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:toolkit/locales/jar.mn>` uses a base path so that the ``.jar`` file is under a ``localization`` directory,
+which is a :searchfox:`special directory parsed by mozbuild <mozilla-central/rev/2005e8d87ee045f19dac58e5bff32eff7d01bc9b:python/mozbuild/mozpack/packager/l10n.py#260-265>`.
 
 It is also named according to the value passed by the variable ``@AB_CD@``, normally a locale. Note the use of the preprocessor directive ``#filter substitution`` at the top of the file for replacing the variable with the value::
 
@@ -87,7 +87,7 @@ It is also named according to the value passed by the variable ``@AB_CD@``, norm
      crashreporter                                    (%crashreporter/**/*.ftl)
      toolkit                                          (%toolkit/**/*.ftl)
 
-The percentage sign in front of the source paths designates the locale to target as a source. By default, this is ``en-US``. With this specific example, `/toolkit/locales/en-US <https://searchfox.org/firefox-main/source/toolkit/locales/en-US>`_ would be targeted.
+The percentage sign in front of the source paths designates the locale to target as a source. By default, this is ``en-US``. With this specific example, :searchfox:`/toolkit/locales/en-US <toolkit/locales/en-US>` would be targeted.
 Otherwise, the file from an alternate localization source tree ``/l10n/<locale>/toolkit/`` is read if building a localized version.
 The wildcards in ``**/*.ftl`` tell the processor to install all Fluent files within the ``crashreporter`` and ``toolkit`` directories, as well as their subdirectories.
 
@@ -111,7 +111,7 @@ an extension.
 Example
 ^^^^^^^
 
-The file `browser/themes/addons/jar.mn <https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/browser/themes/addons/jar.mn>`_ registers a ``resource`` chrome package under the name ``builtin-themes``. Its source files are in ``%content/builtin-themes/``::
+The file :searchfox:`browser/themes/addons/jar.mn <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:browser/themes/addons/jar.mn>` registers a ``resource`` chrome package under the name ``builtin-themes``. Its source files are in ``%content/builtin-themes/``::
 
    browser.jar:
      %  resource builtin-themes %content/builtin-themes/
diff --git a/build/docs/rust.rst b/build/docs/rust.rst
index 2bec50fff764..adffdefdb4c9 100644
--- a/build/docs/rust.rst
+++ b/build/docs/rust.rst
@@ -16,9 +16,9 @@ Linking Rust crates into libxul
 
 Rust crates that you want to link into libxul should be listed in the
 ``dependencies`` section of
-`toolkit/library/rust/shared/Cargo.toml <https://searchfox.org/firefox-main/source/toolkit/library/rust/shared/Cargo.toml>`_.
+:searchfox:`toolkit/library/rust/shared/Cargo.toml`.
 You must also add an ``extern crate`` reference to
-`toolkit/library/rust/shared/lib.rs <https://searchfox.org/firefox-main/source/toolkit/library/rust/shared/lib.rs>`_.
+:searchfox:`toolkit/library/rust/shared/lib.rs`.
 This ensures that the Rust code will be linked properly into libxul as well
 as the copy of libxul used for gtests. (Even though Rust 2018 mostly doesn't
 require ``extern crate`` declarations, these ones are necessary because the
@@ -32,7 +32,7 @@ but --frozen was passed to prevent this"**.
 
 By default, all Cargo packages in the mozilla-central repository are part of
 the same
-`workspace <https://searchfox.org/firefox-main/source/toolkit/library/rust/shared/lib.rs>`_
+:searchfox:`workspace <toolkit/library/rust/shared/lib.rs>`
 and will share the ``Cargo.lock`` file and ``target`` directory in the root of
 the repository.  You can change this behavior by adding a path to the
 ``exclude`` list in the top-level ``Cargo.toml`` file.  You may want to do
@@ -58,7 +58,7 @@ To link Rust code into libraries other than libxul, create a directory with a
     RustLibrary('crate_name')
 
 where ``crate_name`` matches the name from the ``[package]`` section of your
-``Cargo.toml``. You can refer to `the moz.build file <https://searchfox.org/mozilla-central/rev/603b9fded7a11ff213c0f415198cd637b7c86614/toolkit/library/rust/moz.build#9>`_ and `the Cargo.toml file <https://searchfox.org/mozilla-central/rev/603b9fded7a11ff213c0f415198cd637b7c86614/toolkit/library/rust/Cargo.toml>`_ that are used for libxul.
+``Cargo.toml``. You can refer to :searchfox:`the moz.build file <mozilla-central/rev/603b9fded7a11ff213c0f415198cd637b7c86614:toolkit/library/rust/moz.build#9>` and :searchfox:`the Cargo.toml file <mozilla-central/rev/603b9fded7a11ff213c0f415198cd637b7c86614:toolkit/library/rust/Cargo.toml>` that are used for libxul.
 
 You can then add ``USE_LIBS += ['crate_name']`` to the ``moz.build`` file
 that defines the binary as you would with any other library in the tree.
@@ -75,8 +75,7 @@ that defines the binary as you would with any other library in the tree.
 Conditional compilation
 ========================
 
-Edit `tool/library/rust/gkrust-features.mozbuild
-<https://searchfox.org/firefox-main/source/toolkit/library/rust/gkrust-features.mozbuild>`_
+Edit :searchfox:`tool/library/rust/gkrust-features.mozbuild <toolkit/library/rust/gkrust-features.mozbuild>`
 to expose build flags as Cargo features.
 
 Standalone Rust programs
@@ -175,7 +174,7 @@ Finally, make sure you don't accidentally land the changes to the crate or the
 ``Cargo.lock`` file.
 
 For an example of a more complex workflow involving a third-party crate, see
-`mp4parse-rust/README.md <https://searchfox.org/firefox-main/source/media/mp4parse-rust/README.md>`_.
+:searchfox:`mp4parse-rust/README.md <media/mp4parse-rust/README.md>`.
 It describes the workflow for a crate that is hosted on GitHub, and for which
 changes are made via GitHub pull requests, but all pull requests must also be
 tested within mozilla-central before being merged.
diff --git a/build/docs/snap.rst b/build/docs/snap.rst
index 2be08692dd53..2a250da2fd62 100644
--- a/build/docs/snap.rst
+++ b/build/docs/snap.rst
@@ -97,13 +97,12 @@ a cron task daily and includes:
  - building them on all branches
  - running a few selenium-based tests
 
-The build definitions `are based on docker <https://searchfox.org/mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8/taskcluster/docker/snap-coreXX-build/Dockerfile>`_.
+The build definitions :searchfox:`are based on docker <mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8:taskcluster/docker/snap-coreXX-build/Dockerfile>`.
 
 It should be noted that for the moment, all tasks needs to run under docker.
 However, this setup is not working for `Snap` since it interacts with `SystemD`
 which does not work under `Docker`. This is why the installation is handled by
-`the install-snap script
-<https://searchfox.org/mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8/taskcluster/docker/snap-coreXX-build/install-snap.sh>`_
+:searchfox:`the install-snap script <mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8:taskcluster/docker/snap-coreXX-build/install-snap.sh>`
 rather than plain `sudo snap install`, and also why we need to run `snap` in
 `destructive mode` (which is fine since we are within a docker container). This
 does not apply to the tests case which relies on newly-available wayland
@@ -117,8 +116,7 @@ builds are as close as possible to upstream. This means:
    step
  - it builds using the clang build within the snap definition
 
-The tests are defined `within the docker subdirectory
-<https://searchfox.org/mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8/taskcluster/docker/snap-coreXX-build/snap-tests/tests.sh>`_.
+The tests are defined :searchfox:`within the docker subdirectory <mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8:taskcluster/docker/snap-coreXX-build/snap-tests/tests.sh>`.
 They are using Selenium because this is what was used by pre-existing tests ran
 on GitHub Actions from upstream.
 
@@ -131,8 +129,7 @@ How to hack on try
 Build and test tasks can be explored via ``mach try fuzzy --full`` by searching
 for ``'snap 'upstream``. There is a bit of hacking for try to make sure we
 actually don't re-download the mercurial repo and directly reuse the clone
-generated by `run-task`, handled in the `run.sh script
-<https://searchfox.org/mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8/taskcluster/docker/snap-coreXX-build/run.sh#61-72>`_.
+generated by `run-task`, handled in the :searchfox:`run.sh script <mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8:taskcluster/docker/snap-coreXX-build/run.sh#61-72>`.
 
 So pushing to try is basically just:
 
diff --git a/build/docs/test_certificates.rst b/build/docs/test_certificates.rst
index bd482e31a248..f9bb3c206cc7 100644
--- a/build/docs/test_certificates.rst
+++ b/build/docs/test_certificates.rst
@@ -17,9 +17,9 @@ To add a new **CA**, add a ``${cert_name}.ca.keyspec`` as well as a correspondin
 
 .. hint::
 
-   * The full syntax for .certspec files is documented at https://searchfox.org/firefox-main/source/security/manager/tools/pycert.py
+   * The full syntax for .certspec files is documented at :searchfox:`security/manager/tools/pycert.py`
 
-   * The full syntax for .keyspec files is documented at https://searchfox.org/firefox-main/source/security/manager/tools/pykey.py
+   * The full syntax for .keyspec files is documented at :searchfox:`security/manager/tools/pykey.py`
 
 Then regenerate the certificates by running:::
 
diff --git a/build/docs/toolchains.rst b/build/docs/toolchains.rst
index 41c7f9c9d263..dfd7441e6f5b 100644
--- a/build/docs/toolchains.rst
+++ b/build/docs/toolchains.rst
@@ -13,38 +13,30 @@ Clang and Rust
 To modify the toolchains used for a particular task, you may need several
 things:
 
-1. A `build task`_
+1. A :searchfox:`build task <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/build/linux.yml#5-45>`
 
 2. Which uses a toolchain task
 
-    - `clang toolchain`_
-    - `rust toolchain`_
+    - :searchfox:`clang toolchain <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/toolchain/clang.yml#51-72>`
+    - :searchfox:`rust toolchain <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/toolchain/rust.yml#57-74>`
 
 3. Which uses a git fetch
 
-    - `clang fetch`_
-    - (from-source ``dev`` builds only) `rust fetch`_
+    - :searchfox:`clang fetch <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/fetch/toolchains.yml#413-418>`
+    - (from-source ``dev`` builds only) :searchfox:`rust fetch <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/fetch/toolchains.yml#434-439>`
 
-4. (clang only) Which uses a `config json`_
+4. (clang only) Which uses a :searchfox:`config json <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:build/build-clang/clang-linux64.json>`
 
-5. Which takes patches_ you may want to apply.
+5. Which takes :searchfox:`patches <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:build/build-clang/static-llvm-symbolizer.patch>` you may want to apply.
 
 For the most part, you should be able to accomplish what you want by
 copying/editing the existing examples in those files.
 
-.. _build task: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/build/linux.yml#5-45
-.. _clang toolchain: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/toolchain/clang.yml#51-72
-.. _rust toolchain: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/toolchain/rust.yml#57-74
-.. _clang fetch: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/fetch/toolchains.yml#413-418
-.. _rust fetch: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/fetch/toolchains.yml#434-439
-.. _config json: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/build/build-clang/clang-linux64.json
-.. _patches: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/build/build-clang/static-llvm-symbolizer.patch
-
 Clang
 -----
 
-Building clang is handled by `build-clang.py`_, which uses several resources
-in the `build-clang`_ directory. Read the `build-clang README`_ for more
+Building clang is handled by :searchfox:`build-clang.py <build/build-clang/build-clang.py>`, which uses several resources
+in the :searchfox:`build-clang <build/build-clang/>` directory. Read the :searchfox:`build-clang README <build/build-clang/README>` for more
 details.
 
 Note for local builds: build-clang.py can be run on developer machines but its
@@ -52,15 +44,12 @@ lengthy multi-stage build process is unnecessary for most local development. The
 upstream `LLVM Getting Started Guide`_ has instructions on how to build
 clang more directly.
 
-.. _build-clang.py: https://searchfox.org/firefox-main/source/build/build-clang/build-clang.py
-.. _build-clang README: https://searchfox.org/firefox-main/source/build/build-clang/README
-.. _build-clang: https://searchfox.org/firefox-main/source/build/build-clang/
 .. _LLVM Getting Started Guide: https://llvm.org/docs/GettingStarted.html
 
 Rust
 ----
 
-Rust builds are handled by `repack_rust.py`_. The primary purpose of
+Rust builds are handled by :searchfox:`repack_rust.py <taskcluster/scripts/misc/repack_rust.py>`. The primary purpose of
 that script is to download prebuilt tarballs from the Rust project.
 
 It uses the same basic format as `rustup` for specifying the toolchain
@@ -80,22 +69,22 @@ used anywhere by default. The feature was added so that we can test patches
 to rustc against the tree. Expect things to be a bit hacky and limited.
 
 Most importantly, building from source requires your toolchain to have a
-`fetch of the rust tree`_ as well as `clang and binutils toolchains`_. It is also
+:searchfox:`fetch of the rust tree <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/toolchain/rust.yml#69-71>` as well as :searchfox:`clang and binutils toolchains <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/ci/toolchain/rust.yml#72-74>`. It is also
 recommended to upgrade the worker-type to e.g. ``b-linux-large``.
 
 Rust's build dependencies are fairly minimal, and it has a sanity check
 that should catch any missing or too-old dependencies. See the `Rust README`_
 for more details.
 
-Patches are set via `the --patch flag`_ (passed via ``toolchain/rust.yml``).
+Patches are set via :searchfox:`the --patch flag <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/scripts/misc/repack_rust.py#667-675>` (passed via ``toolchain/rust.yml``).
 Patch paths are assumed to be relative to ``/build/build-rust/``, and may be
 optionally prefixed with ``module-path:`` to specify they apply to that git
 submodule in the Rust source. e.g. ``--patch src/llvm-project:mypatch.diff``
 patches rust's llvm with ``/build/build-rust/mypatch.diff``. There are no
 currently checked in rust patches to use as an example, but they should be
-the same format as `the clang ones`_.
+the same format as :searchfox:`the clang ones <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:build/build-clang/static-llvm-symbolizer.patch>`.
 
-Rust builds are not currently configurable, and uses a `hardcoded config.toml`_,
+Rust builds are not currently configurable, and uses a :searchfox:`hardcoded config.toml <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/scripts/misc/repack_rust.py#384-421>`,
 which you may need to edit for your purposes. See Rust's `example config`_ for
 details/defaults. Note that these options do occasionally change, so be sure
 you're using options for the version you're targeting. For instance, there was
@@ -110,22 +99,15 @@ what needs to be done to get this working.
 While Rust generally maintains a clean tree for building ``rustc`` and
 ``cargo``, other tools like ``rustfmt`` or ``miri`` are allowed to be
 transiently broken. This means not every commit in the Rust tree will be
-able to build the `tools we require`_.
+able to build the :searchfox:`tools we require <mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c:taskcluster/scripts/misc/repack_rust.py#398>`.
 
 Although ``repack_rust`` considers ``rustfmt`` an optional package, Rust builds
 do not currently implement this and will fail if ``rustfmt`` is busted. Some
 attempt was made to work around it, but `more work is needed`_.
 
 .. _Rust's ci: https://github.com/rust-lang/rust/pull/77875#issuecomment-736092083
-.. _repack_rust.py: https://searchfox.org/firefox-main/source/taskcluster/scripts/misc/repack_rust.py
-.. _fetch of the rust tree: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/toolchain/rust.yml#69-71
-.. _clang and binutils toolchains: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/ci/toolchain/rust.yml#72-74
-.. _the --patch flag: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/scripts/misc/repack_rust.py#667-675
-.. _the clang ones: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/build/build-clang/static-llvm-symbolizer.patch
 .. _Rust README: https://github.com/rust-lang/rust/#building-on-a-unix-like-system
-.. _hardcoded config.toml: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/scripts/misc/repack_rust.py#384-421
 .. _example config: https://github.com/rust-lang/rust/blob/b7ebc6b0c1ba3c27ebb17c0b496ece778ef11e18/config.toml.example
-.. _tools we require: https://searchfox.org/mozilla-central/rev/168c45a7acc44e9904cfd4eebcb9eb080e05699c/taskcluster/scripts/misc/repack_rust.py#398
 .. _more work is needed: https://github.com/rust-lang/rust/issues/79249
 
 Python
diff --git a/docs/code-quality/coding-style/coding_style_cpp.rst b/docs/code-quality/coding-style/coding_style_cpp.rst
index f1646fc49b64..22b08512a990 100644
--- a/docs/code-quality/coding-style/coding_style_cpp.rst
+++ b/docs/code-quality/coding-style/coding_style_cpp.rst
@@ -354,7 +354,7 @@ C/C++ practices
 ---------------
 
 -  **Have you checked for compiler warnings?** Warnings often point to
-   real bugs. `Many of them <https://searchfox.org/firefox-main/source/build/moz.configure/warnings.configure>`__
+   real bugs. :searchfox:`Many of them <build/moz.configure/warnings.configure>`
    are enabled by default in the build system.
 -  In C++ code, use ``nullptr`` for pointers. In C code, using ``NULL``
    or ``0`` is allowed.
diff --git a/docs/code-quality/coding-style/format_cpp_code_with_clang-format.rst b/docs/code-quality/coding-style/format_cpp_code_with_clang-format.rst
index 8950b33a984a..d247e0ad977e 100644
--- a/docs/code-quality/coding-style/format_cpp_code_with_clang-format.rst
+++ b/docs/code-quality/coding-style/format_cpp_code_with_clang-format.rst
@@ -159,15 +159,13 @@ wrapper).
 
 Coding style configuration is done within clang-format itself. When we
 change the configuration (incorrect configuration, new feature in clang,
-etc), we use `local
-overrides <https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/.clang-format>`__.
+etc), we use :searchfox:`local overrides <mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0:.clang-format>`.
 
 
 Ignored files & directories
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We maintain a `list of ignored directories and
-files <https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/.clang-format-ignore>`__,
+We maintain a :searchfox:`list of ignored directories and files <mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0:.clang-format-ignore>`,
 which is used by ``./mach lint -l clang-format``. This is generally only used
 for code broken by clang-format, and third-party code.
 
@@ -185,8 +183,7 @@ reformat:
    my code which should not be reformatted
    // clang-format on
 
-You can find an `example of code not
-formatted <https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/xpcom/io/nsEscape.cpp#22>`__.
+You can find an :searchfox:`example of code not formatted <mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0:xpcom/io/nsEscape.cpp#22>`.
 
 
 Ignore lists
diff --git a/docs/code-quality/coding-style/rtl_guidelines.rst b/docs/code-quality/coding-style/rtl_guidelines.rst
index 2556a563d1b0..2d8fef6b24f5 100644
--- a/docs/code-quality/coding-style/rtl_guidelines.rst
+++ b/docs/code-quality/coding-style/rtl_guidelines.rst
@@ -92,16 +92,15 @@ What to mirror
 -  Icons or animations that imply directionality or motion like
    back/forward buttons or progress bars
 -  Icons that imply text direction, like
-   `reader-mode.svg <https://searchfox.org/mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174/browser/themes/shared/icons/reader-mode.svg>`__
+   :searchfox:`reader-mode.svg <mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174:browser/themes/shared/icons/reader-mode.svg>`
 -  Icons that imply location of UI elements in the screen, like
-   `sidebar-collapsed-right.svg <https://searchfox.org/firefox-main/rev/b9c3ba706c41c42a7a1b4f6e5b5ba878782b3ab2/browser/themes/shared/icons/sidebar-collapsed-right.svg>`__,
-   `open-in-new.svg <https://searchfox.org/mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174/toolkit/themes/shared/icons/open-in-new.svg>`__,
-   `default theme's preview.svg <https://searchfox.org/mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174/toolkit/mozapps/extensions/default-theme/preview.svg>`__
+   :searchfox:`sidebar-collapsed-right.svg <firefox-main/rev/b9c3ba706c41c42a7a1b4f6e5b5ba878782b3ab2:browser/themes/shared/icons/sidebar-collapsed-right.svg>`,
+   :searchfox:`open-in-new.svg <mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174:toolkit/themes/shared/icons/open-in-new.svg>`,
+   :searchfox:`default theme's preview.svg <mozilla-central/rev/f9beb753a84aa297713d1565dcd0c5e3c66e4174:toolkit/mozapps/extensions/default-theme/preview.svg>`
    or
-   `pane-collapse.svg <https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/devtools/client/debugger/images/pane-collapse.svg>`__
+   :searchfox:`pane-collapse.svg <mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212:devtools/client/debugger/images/pane-collapse.svg>`
 -  Icons representing objects that are meant to be handheld should look
-   like they're being right-handed, like the `magnifying glass
-   icon <https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/toolkit/themes/windows/global/icons/search-textbox.svg>`__
+   like they're being right-handed, like the :searchfox:`magnifying glass icon <mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f:toolkit/themes/windows/global/icons/search-textbox.svg>`
 -  Twisties in their collapsed state. Note that if the context in which
    they appear is LTR (e.g. code in a devtools HTML view), they should
    not be mirrored, even if the user might be using an RTL locale.
@@ -112,14 +111,12 @@ What NOT to mirror
 -  Text/numbers
 -  Icons containing text/numbers
 -  Icons/animations that are direction neutral
--  Icons that wouldn't look differently if they'd be mirrored, like `X
-   buttons <https://searchfox.org/mozilla-central/rev/a78233c11a6baf2c308fbed17eb16c6e57b6a2ac/devtools/client/debugger/images/close.svg>`__
-   or the `bookmark
-   star <https://searchfox.org/mozilla-central/rev/a78233c11a6baf2c308fbed17eb16c6e57b6a2ac/browser/themes/shared/icons/bookmark-hollow.svg>`__
+-  Icons that wouldn't look differently if they'd be mirrored, like :searchfox:`X buttons <mozilla-central/rev/a78233c11a6baf2c308fbed17eb16c6e57b6a2ac:devtools/client/debugger/images/close.svg>`
+   or the :searchfox:`bookmark star <mozilla-central/rev/a78233c11a6baf2c308fbed17eb16c6e57b6a2ac:browser/themes/shared/icons/bookmark-hollow.svg>`
    icon, or any other symmetric icon
 -  Icons that should look the same as LTR, like icons related to code
    (which is always LTR) like
-   `tool-webconsole.svg <https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/devtools/client/themes/images/tool-webconsole.svg>`__
+   :searchfox:`tool-webconsole.svg <mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212:devtools/client/themes/images/tool-webconsole.svg>`
 -  Checkmark icons
 -  Video/audio player controls
 -  Product logos
diff --git a/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst b/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst
index 005abbabdd2d..ccdbb1bea743 100644
--- a/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst
+++ b/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst
@@ -315,12 +315,11 @@ rvalue references
 
 Attributes
   Several common attributes are defined in
-  `mozilla/Attributes.h <https://searchfox.org/firefox-main/source/mfbt/Attributes.h>`__
+  :searchfox:`mozilla/Attributes.h <mfbt/Attributes.h>`
   or nscore.h.
 
 Alignment
-  Some alignment utilities are defined in `mozilla/Alignment.h
-  <https://searchfox.org/firefox-main/source/mfbt/Alignment.h>`__.
+  Some alignment utilities are defined in :searchfox:`mozilla/Alignment.h <mfbt/Alignment.h>`.
 
 ``[[deprecated]]``
   If we have deprecated code, we should be removing it rather than marking it as
@@ -388,7 +387,7 @@ memory size tracking) or have more controllable performance
 characteristics.
 
 A list of approved standard library headers is maintained in
-`config/stl-headers.mozbuild <https://searchfox.org/firefox-main/source/config/stl-headers.mozbuild>`__.
+:searchfox:`config/stl-headers.mozbuild`.
 
 
 Data structures
@@ -439,7 +438,7 @@ Data structures
      -
      - Like ``std::set``, but for enum classes.
    * - ``mozilla::Hash{Map,Set}``
-     - `mozilla/HashTable.h <https://searchfox.org/firefox-main/source/mfbt/HashTable.h>`__
+     - :searchfox:`mozilla/HashTable.h <mfbt/HashTable.h>`
      - ``std::unordered_{map,set}``
      - A general purpose hash map and hash set.
    * - ``nsInterfaceHashtable``
diff --git a/docs/code-quality/index.rst b/docs/code-quality/index.rst
index 5888818cda41..59eedafc4679 100644
--- a/docs/code-quality/index.rst
+++ b/docs/code-quality/index.rst
@@ -27,7 +27,7 @@ In this document, we try to list these all tools.
    * - Custom clang checker
      -
      -
-     - `Source <https://searchfox.org/firefox-main/source/build/clang-plugin>`_
+     - :searchfox:`Source <build/clang-plugin>`
      -
    * - Clang-Tidy
      - Yes
diff --git a/docs/code-quality/lint/create.rst b/docs/code-quality/lint/create.rst
index 9c375a8835d6..25df74fb7315 100644
--- a/docs/code-quality/lint/create.rst
+++ b/docs/code-quality/lint/create.rst
@@ -106,7 +106,7 @@ Example
 -------
 
 Here is an example of an external linter that shells out to the Python ruff linter,
-let's call the file ``ruff_lint.py`` (`in-tree version <https://searchfox.org/firefox-main/source/tools/lint/python/ruff.py>`__):
+let's call the file ``ruff_lint.py`` (:searchfox:`in-tree version <tools/lint/python/ruff.py>`):
 
 .. code-block:: python
 
@@ -224,7 +224,7 @@ They should be pretty easy to write as most of the work is managed by the Mozlin
 framework. The key declaration is the ``LINTER`` variable which must match
 the linker declaration.
 
-As an example, the `ruff test <https://searchfox.org/firefox-main/source/tools/lint/test/test_ruff.py>`_ looks like the following snippet:
+As an example, the :searchfox:`ruff test <tools/lint/test/test_ruff.py>` looks like the following snippet:
 
 .. code-block:: python
 
@@ -256,7 +256,7 @@ To run a specific test:
 
     ./mach python-test --subsuite mozlint tools/lint/test/test_black.py
 
-More tests can be `found in-tree <https://searchfox.org/firefox-main/source/tools/lint/test>`_.
+More tests can be :searchfox:`found in-tree <tools/lint/test>`.
 
 Tracking fixed issues
 ---------------------
@@ -268,8 +268,8 @@ All the linters that provide ``fix support`` returns a dictionary instead of a l
 * results - All the linting errors it was not able to fix
 * fixed - Count of fixed errors (for ``fix=False`` this is 0)
 
-Some linters (example: `codespell <https://searchfox.org/mozilla-central/rev/0379f315c75a2875d716b4f5e1a18bf27188f1e6/tools/lint/spell/__init__.py#145-163>`_) might require two passes to count the number of fixed issues.
-Others might just need `some tuning <https://searchfox.org/mozilla-central/rev/0379f315c75a2875d716b4f5e1a18bf27188f1e6/tools/lint/file-whitespace/__init__.py#28,60,85,112>`_.
+Some linters (example: :searchfox:`codespell <mozilla-central/rev/0379f315c75a2875d716b4f5e1a18bf27188f1e6:tools/lint/spell/__init__.py#145-163>`) might require two passes to count the number of fixed issues.
+Others might just need :searchfox:`some tuning <mozilla-central/rev/0379f315c75a2875d716b4f5e1a18bf27188f1e6:tools/lint/file-whitespace/__init__.py#28,60,85,112>`.
 
 For adding tests to check your fixed count, add a global variable ``fixed = 0``
 and write a function to add your test as mentioned under ``Automated testing`` section.
@@ -308,7 +308,7 @@ complicated as pulling a whole graph of tools, plugins and their dependencies.
 Either way, to reduce the burden on users, linters should strive to provide
 automated bootstrapping of all their dependencies. To help with this,
 ``mozlint`` allows linters to define a ``setup`` config, which has the same
-path object format as an external payload. For example (`in-tree version <https://searchfox.org/firefox-main/source/tools/lint/ruff.yml>`__):
+path object format as an external payload. For example (:searchfox:`in-tree version <tools/lint/ruff.yml>`):
 
 .. code-block:: yaml
 
@@ -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/firefox-main/source/taskcluster/kinds/source-test/mozlint.yml>`_.
+This should be done in the :searchfox:`mozlint Taskcluster configuration <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:
@@ -365,8 +365,8 @@ For example, for ruff, the configuration is the following:
                 - '**/*.py'
                 - '**/.ruff.toml'
 
-If the linter requires an external program, you will have to install it in the `setup script <https://searchfox.org/firefox-main/source/taskcluster/docker/lint/system-setup.sh>`_
-and maybe install the necessary files in the `Docker configuration <https://searchfox.org/firefox-main/source/taskcluster/docker/lint/Dockerfile>`_.
+If the linter requires an external program, you will have to install it in the :searchfox:`setup script <taskcluster/docker/lint/system-setup.sh>`
+and maybe install the necessary files in the :searchfox:`Docker configuration <taskcluster/docker/lint/Dockerfile>`.
 
 .. note::
 
diff --git a/docs/code-quality/lint/linters/clippy.rst b/docs/code-quality/lint/linters/clippy.rst
index 1571e478bc4c..9275c9a10187 100644
--- a/docs/code-quality/lint/linters/clippy.rst
+++ b/docs/code-quality/lint/linters/clippy.rst
@@ -33,7 +33,7 @@ Configuration
 -------------
 
 To enable clippy on new directory, add the path to the include
-section in the `clippy.yml <https://searchfox.org/firefox-main/source/tools/lint/clippy.yml>`_ file.
+section in the :searchfox:`clippy.yml <tools/lint/clippy.yml>` file.
 
 To enable additional clippy rules beyond the defaults, add them to the
 ``warn`` or ``deny`` lists in `clippy.yml <https://searchfox.org/mozilla-central/source/tools/lint/clippy.yml>`_:
@@ -51,5 +51,5 @@ The full list of available lints is at https://rust-lang.github.io/rust-clippy/m
 Sources
 -------
 
-* `Configuration (YAML) <https://searchfox.org/firefox-main/source/tools/lint/clippy.yml>`_
-* `Source <https://searchfox.org/firefox-main/source/tools/lint/clippy/__init__.py>`_
+* :searchfox:`Configuration (YAML) <tools/lint/clippy.yml>`
+* :searchfox:`Source <tools/lint/clippy/__init__.py>`
diff --git a/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-importGlobalProperties.rst b/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-importGlobalProperties.rst
index 60e2a3887be2..b8124e9ef6f0 100644
--- a/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-importGlobalProperties.rst
+++ b/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-importGlobalProperties.rst
@@ -9,7 +9,7 @@ non-module code or non-system modules, webidl defined interfaces should already
 be available and hence do not need importing.
 
 For sjs test files, if the relevant global is not already available, then consider
-extending the `list of globals available from the httpd server <https://searchfox.org/mozilla-central/rev/e9b338c2d597067f99e96d5f20769f41f312fa8f/netwerk/test/httpserver/httpd.sys.mjs#2875-2889>`_.
+extending the :searchfox:`list of globals available from the httpd server <mozilla-central/rev/e9b338c2d597067f99e96d5f20769f41f312fa8f:netwerk/test/httpserver/httpd.sys.mjs#2875-2889>`.
 
 Options
 -------
diff --git a/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-scriptableunicodeconverter.rst b/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-scriptableunicodeconverter.rst
index 982aa699b6c8..4d1a4c1eddf0 100644
--- a/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-scriptableunicodeconverter.rst
+++ b/docs/code-quality/lint/linters/eslint-plugin-mozilla/rules/reject-scriptableunicodeconverter.rst
@@ -7,7 +7,7 @@ If modifying old code, please consider swapping it in if possible; if this is tr
 a bug is on file.
 
 .. |TextEncoder| replace:: ``TextEncoder``
-.. _TextEncoder: https://searchfox.org/firefox-main/source/dom/webidl/TextEncoder.webidl
+.. _TextEncoder: :searchfox:`dom/webidl/TextEncoder.webidl`
 
 .. |TextDecoder| replace:: ``TextDecoder``
-.. _TextDecoder: https://searchfox.org/firefox-main/source/dom/webidl/TextDecoder.webidl
+.. _TextDecoder: :searchfox:`dom/webidl/TextDecoder.webidl`
diff --git a/docs/code-quality/lint/linters/eslint.rst b/docs/code-quality/lint/linters/eslint.rst
index 6f712bc29c40..3d11916f8ccd 100644
--- a/docs/code-quality/lint/linters/eslint.rst
+++ b/docs/code-quality/lint/linters/eslint.rst
@@ -92,7 +92,7 @@ it is not possible to scope ESLint rules to individual files based on .ini
 files without a build step that would break editors, or an expensive loading
 cycle.
 
-* If the directory path of the tests is one of the `known ones`_, then ESLint will
+* If the directory path of the tests is one of the :searchfox:`known ones <mozilla-central/rev/287583a4a605eee8cd2d41381ffaea7a93d7b987:.eslintrc.js#24-40>`, then ESLint will
   do the right thing for that test type. This is the preferred option.
 
   * For example placing xpcshell-tests in ``browser/components/foo/test/unit/``
@@ -215,9 +215,8 @@ For test harness issues, file bugs in Developer Infrastructure :: Lint and Forma
 .. _eslint.org's rule list: https://eslint.org/docs/rules/
 .. _eslint-plugin-mozilla: eslint-plugin-mozilla.html
 .. _eslint-plugin-spidermonkey-js: eslint-plugin-spidermonkey-js.html
-.. _informed that it is a module: https://searchfox.org/mozilla-central/rev/9399e5832979755cd340383f4ca4069dd5fc7774/browser/base/content/.eslintrc.js
+.. _informed that it is a module: :searchfox:`mozilla-central/rev/9399e5832979755cd340383f4ca4069dd5fc7774:browser/base/content/.eslintrc.js`
 .. _seek help: ../index.html#getting-help
-.. _patterns in .eslintrc.js: https://searchfox.org/mozilla-central/rev/9399e5832979755cd340383f4ca4069dd5fc7774/.eslintrc.js#24-38
-.. _known ones: https://searchfox.org/mozilla-central/rev/287583a4a605eee8cd2d41381ffaea7a93d7b987/.eslintrc.js#24-40
+.. _patterns in .eslintrc.js: :searchfox:`mozilla-central/rev/9399e5832979755cd340383f4ca4069dd5fc7774:.eslintrc.js#24-38`
 .. _difficult for ESLint to handle: https://bugzilla.mozilla.org/show_bug.cgi?id=1379669
 .. _prettier ignore docs: https://prettier.io/docs/en/ignore.html
diff --git a/docs/code-quality/lint/linters/gecko-trace.rst b/docs/code-quality/lint/linters/gecko-trace.rst
index 8da7a5de8b0c..8a24b7f4faee 100644
--- a/docs/code-quality/lint/linters/gecko-trace.rst
+++ b/docs/code-quality/lint/linters/gecko-trace.rst
@@ -29,5 +29,5 @@ This linter provides a ``--fix`` option for the ``generated-metrics.yaml`` file.
 Sources
 -------
 
-* `Configuration (YAML) <https://searchfox.org/firefox-main/source/tools/lint/gecko-trace.yml>`_
-* `Source <https://searchfox.org/firefox-main/source/tools/lint/gecko-trace/__init__.py>`_
+* :searchfox:`Configuration (YAML) <tools/lint/gecko-trace.yml>`
+* :searchfox:`Source <tools/lint/gecko-trace/__init__.py>`
diff --git a/docs/code-quality/lint/linters/license.rst b/docs/code-quality/lint/linters/license.rst
index e4484985d9d3..04fddcf744d5 100644
--- a/docs/code-quality/lint/linters/license.rst
+++ b/docs/code-quality/lint/linters/license.rst
@@ -5,8 +5,7 @@ This linter verifies if a file has a known license header.
 
 By default, Firefox uses MPL-2 license with the `appropriate headers <https://www.mozilla.org/en-US/MPL/headers/>`_.
 In some cases (thirdpardy code), a file might have a different header file.
-If this is the case, one of the significant line of the header should be listed in the list `of valid licenses
-<https://searchfox.org/firefox-main/source/tools/lint/license/valid-licenses.txt>`_.
+If this is the case, one of the significant line of the header should be listed in the list :searchfox:`of valid licenses <tools/lint/license/valid-licenses.txt>`.
 
 Run Locally
 -----------
diff --git a/docs/code-quality/lint/linters/perfdocs.rst b/docs/code-quality/lint/linters/perfdocs.rst
index 1926c0b79748..6f3791294660 100644
--- a/docs/code-quality/lint/linters/perfdocs.rst
+++ b/docs/code-quality/lint/linters/perfdocs.rst
@@ -120,10 +120,10 @@ Metrics that produce alerts can also be documented like so:
 
 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/firefox-main/source/tools/lint/perfdocs/framework_gatherers.py>`_ for an example gatherer that was implemented for Raptor.
+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 :searchfox:`RaptorGatherer <tools/lint/perfdocs/framework_gatherers.py>` for an example gatherer that was implemented for Raptor.
 
 Sources
 -------
 
-* `Configuration <https://searchfox.org/firefox-main/source/tools/lint/perfdocs.yml>`__
-* `Source <https://searchfox.org/firefox-main/source/tools/lint/perfdocs>`__
+* :searchfox:`Configuration <tools/lint/perfdocs.yml>`
+* :searchfox:`Source <tools/lint/perfdocs>`
diff --git a/docs/code-quality/lint/linters/ruff.rst b/docs/code-quality/lint/linters/ruff.rst
index 5d5de6332ba3..a6742cb5efda 100644
--- a/docs/code-quality/lint/linters/ruff.rst
+++ b/docs/code-quality/lint/linters/ruff.rst
@@ -25,7 +25,7 @@ The mozlint integration of ruff can be run using mach:
 Configuration
 -------------
 
-Ruff is configured in the root `pyproject.toml`_ file. Additionally, ruff will
+Ruff is configured in the root :searchfox:`pyproject.toml` file. Additionally, ruff will
 pick up any ``pyproject.toml`` or ``ruff.toml`` files in subdirectories. The
 settings in these files will only apply to files contained within these
 subdirs. For more details on configuration discovery, see the `configuration
@@ -36,9 +36,8 @@ For a list of options, see the `settings documentation`_.
 Sources
 -------
 
-* `Configuration (YAML) <https://searchfox.org/firefox-main/source/tools/lint/ruff.yml>`_
-* `Source <https://searchfox.org/firefox-main/source/tools/lint/python/ruff.py>`_
+* :searchfox:`Configuration (YAML) <tools/lint/ruff.yml>`
+* :searchfox:`Source <tools/lint/python/ruff.py>`
 
-.. _pyproject.toml: https://searchfox.org/firefox-main/source/pyproject.toml
 .. _configuration documentation: https://beta.ruff.rs/docs/configuration/
 .. _settings documentation: https://beta.ruff.rs/docs/settings/
diff --git a/docs/code-quality/lint/linters/test-manifest-toml.rst b/docs/code-quality/lint/linters/test-manifest-toml.rst
index 0844ad2a4d89..8fb3787f70ab 100644
--- a/docs/code-quality/lint/linters/test-manifest-toml.rst
+++ b/docs/code-quality/lint/linters/test-manifest-toml.rst
@@ -168,8 +168,8 @@ Platforms that are currently supported in CI
 Sources
 -------
 
-* `Configuration (YAML) <https://searchfox.org/firefox-main/source/tools/lint/test-manifest-toml.yml>`_
-* `Source <https://searchfox.org/firefox-main/source/tools/lint/test-manifest-toml/__init__.py>`_
+* :searchfox:`Configuration (YAML) <tools/lint/test-manifest-toml.yml>`
+* :searchfox:`Source <tools/lint/test-manifest-toml/__init__.py>`
 
 Developer Information
 ---------------------
diff --git a/docs/code-quality/static-analysis/writing-new/adding-a-check.rst b/docs/code-quality/static-analysis/writing-new/adding-a-check.rst
index 142cb627884a..c130262199ce 100644
--- a/docs/code-quality/static-analysis/writing-new/adding-a-check.rst
+++ b/docs/code-quality/static-analysis/writing-new/adding-a-check.rst
@@ -5,7 +5,7 @@ Adding a check
 
 After you've completed a matcher using clang-query, it's time to take it to the next step and turn it into C++ and run it on the whole m-c codebase and see what happens.
 
-Clang plugins live in `build/clang-plugin <https://searchfox.org/firefox-main/source/build/clang-plugin>`_ and here we'll cover what is needed to add one. To see how the most recent check was added, you can look at the log for `Checks.inc <https://hg.mozilla.org/mozilla-central/log/tip/build/clang-plugin/Checks.inc>`_ which is one of the necessary files to edit.  That's also what we'll be covering next.
+Clang plugins live in :searchfox:`build/clang-plugin` and here we'll cover what is needed to add one. To see how the most recent check was added, you can look at the log for `Checks.inc <https://hg.mozilla.org/mozilla-central/log/tip/build/clang-plugin/Checks.inc>`_ which is one of the necessary files to edit.  That's also what we'll be covering next.
 
 Boilerplate Steps to Add a New Check
 ------------------------------------
@@ -14,7 +14,7 @@ First pick a name. Pick something that makes sense without punctuation, in no mo
 
 #. Add it alphabetically in build/clang-plugin/Checks.inc, ChecksIncludes.inc, and moz.build
 #. ``cd build/clang-plugin && touch MissingElseInEnumComparisons.h MissingElseInEnumComparisons.cpp``
-#. Copy the contents of an existing, simple .h file (e.g. `build/clang-plugin/ScopeChecker.h <https://searchfox.org/firefox-main/source/build/clang-plugin/ScopeChecker.h>`_) and edit the class name and header guards.
+#. Copy the contents of an existing, simple .h file (e.g. :searchfox:`build/clang-plugin/ScopeChecker.h`) and edit the class name and header guards.
 #. Create the following boilerplate for your implementation:
 
 ::
diff --git a/docs/code-quality/static-analysis/writing-new/advanced-check-features.rst b/docs/code-quality/static-analysis/writing-new/advanced-check-features.rst
index dc3dd4c9b6f1..cfcce65c3a70 100644
--- a/docs/code-quality/static-analysis/writing-new/advanced-check-features.rst
+++ b/docs/code-quality/static-analysis/writing-new/advanced-check-features.rst
@@ -8,7 +8,7 @@ This page covers additional ways to improve and extend the check you've added to
 Adding Tests
 ------------
 
-No doubt you've seen the tests for existing checks in `build/clang-plugin/tests <https://searchfox.org/firefox-main/source/build/clang-plugin/tests>`_. Adding tests is straightforward; and your reviewer should insist you do so. Simply copying the existing format of any test and how diagnostics are marked as expected.
+No doubt you've seen the tests for existing checks in :searchfox:`build/clang-plugin/tests`. Adding tests is straightforward; and your reviewer should insist you do so. Simply copying the existing format of any test and how diagnostics are marked as expected.
 
 One wrinkle - all clang plugin checks are applied to all tests. We try to write tests so that only one check applies to it.  If you write a check that triggers on an existing test, try to fix the existing test slightly so the new check does not trigger on it.
 
diff --git a/docs/code-quality/static-analysis/writing-new/clang-query.rst b/docs/code-quality/static-analysis/writing-new/clang-query.rst
index 8b8243a5c041..5d691b17fe4d 100644
--- a/docs/code-quality/static-analysis/writing-new/clang-query.rst
+++ b/docs/code-quality/static-analysis/writing-new/clang-query.rst
@@ -4,8 +4,7 @@ Using clang-query
 =================
 
 clang-query is a tool that allows you to quickly iterate and develop the difficult part of a matcher.
-Once the design of the matcher is completed, it can be transferred to a C++ clang-tidy plugin, `similar
-to the ones in mozilla-central <https://searchfox.org/firefox-main/source/build/clang-plugin>`_.
+Once the design of the matcher is completed, it can be transferred to a C++ clang-tidy plugin, :searchfox:`similar to the ones in mozilla-central <build/clang-plugin>`.
 
 Recommended Boilerplate
 -----------------------
diff --git a/docs/content-security/index.rst b/docs/content-security/index.rst
index cb1132ded1d5..7e1e3c2c1a87 100644
--- a/docs/content-security/index.rst
+++ b/docs/content-security/index.rst
@@ -103,6 +103,6 @@ References
 ----------
 The interface definition in source code have a lot of detailed comments:
 
-- The `nsIPrincipal <https://searchfox.org/firefox-main/source/caps/nsIPrincipal.idl>`_ interface definition.
-- The `nsILoadInfo <https://searchfox.org/firefox-main/source/netwerk/base/nsILoadInfo.idl>`_ interface definition.
-- The `nsIContentSecurityManager <https://searchfox.org/firefox-main/source/dom/interfaces/security/nsIContentSecurityManager.idl>`_ interface definition
+- The :searchfox:`nsIPrincipal <caps/nsIPrincipal.idl>` interface definition.
+- The :searchfox:`nsILoadInfo <netwerk/base/nsILoadInfo.idl>` interface definition.
+- The :searchfox:`nsIContentSecurityManager <dom/interfaces/security/nsIContentSecurityManager.idl>` interface definition
diff --git a/docs/contributing/build/building_mobile_firefox.rst b/docs/contributing/build/building_mobile_firefox.rst
index c79e8c9b5526..641410f94711 100644
--- a/docs/contributing/build/building_mobile_firefox.rst
+++ b/docs/contributing/build/building_mobile_firefox.rst
@@ -8,7 +8,7 @@ devices, and audiences:
    mobile browser is split into several different artifact layers:
 
   - `The fenix Android application </mobile/android/fenix.html>`_
-  - `The android-components Android library <https://searchfox.org/firefox-main/source/mobile/android/android-components>`_
+  - :searchfox:`The android-components Android library <mobile/android/android-components>`
   - `The GeckoView platform </mobile/android/geckoview>`_
 
 -  `Firefox for iOS <https://github.com/mozilla-mobile/firefox-ios>`_,
@@ -16,7 +16,7 @@ devices, and audiences:
 -  Building **Firefox Focus**, our privacy-focused browser for
 
   - `iOS <https://github.com/mozilla-mobile/focus-ios>`_
-  - `Android <https://searchfox.org/firefox-main/source/mobile/android/focus-android>`_. This browser
+  - :searchfox:`Android <mobile/android/focus-android>`. This browser
     also uses the android-components library and GeckoView platform, like Firefox for Android
 
 For both Desktop and Mobile development, please bear the following in
diff --git a/docs/contributing/contributing_to_mozilla.rst b/docs/contributing/contributing_to_mozilla.rst
index adc93887d35d..e89c58e38b3c 100644
--- a/docs/contributing/contributing_to_mozilla.rst
+++ b/docs/contributing/contributing_to_mozilla.rst
@@ -35,7 +35,7 @@ very diverse skills:
 -  If you know **Rust**, you can also contribute to the `Rust programming
    language <https://github.com/rust-lang/rust>`_ itself, numerous crates like `grcov <https://github.com/mozilla/grcov/>`_
    or `Servo <https://servo.org/>`_, the web browser engine designed for parallelism and safety.
--  If you know **Kotlin**, you can contribute to :ref:`Firefox for Android <Firefox Contributors' Quick Reference>` (code name: "Fenix"). `Fenix's code <https://searchfox.org/firefox-main/source/mobile/android/>`_ is integrated into the same repository as Firefox Desktop.
+-  If you know **Kotlin**, you can contribute to :ref:`Firefox for Android <Firefox Contributors' Quick Reference>` (code name: "Fenix"). :searchfox:`Fenix's code <mobile/android/>` is integrated into the same repository as Firefox Desktop.
 -  If you know **Swift**, you can contribute to `Firefox for
    iOS <https://github.com/mozilla-mobile/firefox-ios>`_ and `Firefox
    Focus for iOS <https://github.com/mozilla-mobile/focus-ios>`_.
diff --git a/docs/contributing/debugging/debugging_firefox_with_lldb.rst b/docs/contributing/debugging/debugging_firefox_with_lldb.rst
index 0a04254fde73..a9f3c890f1c0 100644
--- a/docs/contributing/debugging/debugging_firefox_with_lldb.rst
+++ b/docs/contributing/debugging/debugging_firefox_with_lldb.rst
@@ -7,11 +7,11 @@ Mozilla-specific lldb settings
 ------------------------------
 
 There's an
-``.lldbinit`` `file <https://searchfox.org/firefox-main/source/.lldbinit>`_
+``.lldbinit`` :searchfox:`file <.lldbinit>`
 in the Mozilla source tree, which applies recommended settings and
 includes a few type summaries and Mozilla-specific debugging commands
 via the lldbutils module (see
-`python/lldbutils/README.txt <https://searchfox.org/firefox-main/source/python/lldbutils/README.txt>`__).
+:searchfox:`python/lldbutils/README.txt`).
 For information about available features see the links above and the `Using
 LLDB to debug Gecko <http://mcc.id.au/blog/2014/01/lldb-gecko>`__ blog
 post.
diff --git a/docs/contributing/debugging/debugging_firefox_with_valgrind.rst b/docs/contributing/debugging/debugging_firefox_with_valgrind.rst
index 066f8c8bfcda..aff728df3d3a 100644
--- a/docs/contributing/debugging/debugging_firefox_with_valgrind.rst
+++ b/docs/contributing/debugging/debugging_firefox_with_valgrind.rst
@@ -111,7 +111,7 @@ Advanced usage
 Shared suppression files
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-`/build/valgrind/ <https://searchfox.org/firefox-main/source/build/valgrind/>`__
+:searchfox:`/build/valgrind/ <build/valgrind/>`
 contains the suppression files used by the periodic Valgrind jobs on
 Treeherder. Some of these files are platform-specific.
 
diff --git a/docs/contributing/debugging/debugging_on_macos.rst b/docs/contributing/debugging/debugging_on_macos.rst
index 6673e86cf6cb..00c33f073e39 100644
--- a/docs/contributing/debugging/debugging_on_macos.rst
+++ b/docs/contributing/debugging/debugging_on_macos.rst
@@ -179,10 +179,8 @@ Setting up lldb
    lldb <Debugging Firefox with LLDB>`.
 
 The
-`.lldbinit <http://searchfox.org/firefox-main/source/.lldbinit>`__
-file in the source tree imports many useful `Mozilla specific lldb
-settings, commands and
-formatters <https://searchfox.org/firefox-main/source/python/lldbutils/README.txt>`__
+:searchfox:`.lldbinit`
+file in the source tree imports many useful :searchfox:`Mozilla specific lldb settings, commands and formatters <python/lldbutils/README.txt>`
 into ``lldb``, but you may need to take one of the following steps to
 make sure this file is used.
 
diff --git a/docs/contributing/debugging/debugging_on_windows.rst b/docs/contributing/debugging/debugging_on_windows.rst
index 8a6d53fd69c7..704d2515910b 100644
--- a/docs/contributing/debugging/debugging_on_windows.rst
+++ b/docs/contributing/debugging/debugging_on_windows.rst
@@ -274,7 +274,7 @@ Debugging JavaScript
 ~~~~~~~~~~~~~~~~~~~~
 
 You can use helper functions from
-`nsXPConnect.cpp <https://searchfox.org/firefox-main/source/js/xpconnect/src/nsXPConnect.cpp>`__
+:searchfox:`nsXPConnect.cpp <js/xpconnect/src/nsXPConnect.cpp>`
 to inspect and modify the state of JavaScript code from the MSVS
 debugger.
 
diff --git a/docs/contributing/debugging/debugging_webrtc_calls.rst b/docs/contributing/debugging/debugging_webrtc_calls.rst
index ad04e6fe7fde..97a1d75724e2 100644
--- a/docs/contributing/debugging/debugging_webrtc_calls.rst
+++ b/docs/contributing/debugging/debugging_webrtc_calls.rst
@@ -890,7 +890,7 @@ test types.
 .. code:: bash
 
    # Run a single test by using Prefix.TestName, e.g. JsepSessionTest.FullCall
-   # https://searchfox.org/mozilla-central/rev/4d6a5b97428760d15bfcad13f8fc81439370a7ec/media/webrtc/signaling/gtest/jsep_session_unittest.cpp#1551
+   # :searchfox:`mozilla-central/rev/4d6a5b97428760d15bfcad13f8fc81439370a7ec:media/webrtc/signaling/gtest/jsep_session_unittest.cpp#1551`
    ./mach gtest 'JsepSessionTest.FullCall'
 
    # Run all the tests in a single Prefix, e.g. JsepSessionTest
@@ -913,20 +913,20 @@ Here is a list of helpful substring selectors for executing specific WebRTC gtes
      - Files
    * - :code:`*Jsep*`
      - JSEP (signalling) tests
-     - `jsep_session_unittest.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/jsep_session_unittest.cpp>`__
-       `jsep_trak_unittest.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/jsep_track_unittest.cpp>`__
+     - :searchfox:`jsep_session_unittest.cpp <media/webrtc/signaling/gtest/jsep_session_unittest.cpp>`
+       :searchfox:`jsep_trak_unittest.cpp <media/webrtc/signaling/gtest/jsep_track_unittest.cpp>`
    * - :code:`*Sdp*`
      - SDP parsing tests
-     - `sdp_unittests.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/sdp_unittests.cpp>`__
+     - :searchfox:`sdp_unittests.cpp <media/webrtc/signaling/gtest/sdp_unittests.cpp>`
    * - :code:`*MediaPipeline*`
      - MediaPipline and MediaPipeline filter tests for RTP media handling
-     - `mediapipeline_unittest.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/mediapipeline_unittest.cpp>`__
+     - :searchfox:`mediapipeline_unittest.cpp <media/webrtc/signaling/gtest/mediapipeline_unittest.cpp>`
    * - :code:`*AudioConduit*`
      - AudioConduit tests for libwebrtc glue for RTP audio media
-     - `audioconduit_unittests.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/audioconduit_unittests.cpp>`__
+     - :searchfox:`audioconduit_unittests.cpp <media/webrtc/signaling/gtest/audioconduit_unittests.cpp>`
    * - :code:`*VideoConduit*`
      - VideoConduit tests for libwebrtc glue for RTP video media
-     - `videoconduit_unittests.cpp <https://searchfox.org/firefox-main/source/media/webrtc/signaling/gtest/videoconduit_unittests.cpp>`__
+     - :searchfox:`videoconduit_unittests.cpp <media/webrtc/signaling/gtest/videoconduit_unittests.cpp>`
 
 For more general information about gtests see the documentation `here </gtest/index.html>`__.
 
@@ -955,115 +955,115 @@ provided below to help one navigate.
      - Component
      - Description
      - Notes
-   * - `dom/media/webrtc <https://searchfox.org/firefox-main/source/dom/media/webrtc>`__
+   * - :searchfox:`dom/media/webrtc`
      - WebRTC
      - This is the primary directory for Firefox WebRTC code
      -
-   * - `dom/media/webrtc/common <https://searchfox.org/firefox-main/source/dom/media/webrtc/common>`__
+   * - :searchfox:`dom/media/webrtc/common`
      - WebRTC
      - This contains WebRTC related utility code
      -
-   * - `dom/media/webrtc/jsapi <https://searchfox.org/firefox-main/source/dom/media/webrtc/jsapi>`__
+   * - :searchfox:`dom/media/webrtc/jsapi`
      - JS API
      - This contains the C++ implementations of the JavaScript WebRTC interfaces
      -
-   * - `dom/media/webrtc/jsep <https://searchfox.org/firefox-main/source/dom/media/webrtc/jsep>`__
+   * - :searchfox:`dom/media/webrtc/jsep`
      - Signalling
      - This is the JSEP state engine implementation
      -
-   * - `dom/media/webrtc/libwebrtcglue <https://searchfox.org/firefox-main/source/dom/media/webrtc/libwebrtcglue>`__
+   * - :searchfox:`dom/media/webrtc/libwebrtcglue`
      - WebRTC (various)
      - This is the glue code between libwebrtc and Firefox
      -
-   * - `dom/media/webrtc/libwebrtc_overrides <https://searchfox.org/firefox-main/source/dom/media/webrtc/libwebrtc_overrides>`__
+   * - :searchfox:`dom/media/webrtc/libwebrtc_overrides`
      - WebRTC (various)
      - Firefox-specific overrides for libwebrtc components
      -
-   * - `dom/media/webrtc/sdp <https://searchfox.org/firefox-main/source/dom/media/webrtc/sdp>`__
+   * - :searchfox:`dom/media/webrtc/sdp`
      - Signalling
      - This contains the SDP parsing interface
      -
-   * - `dom/media/webrtc/tests <https://searchfox.org/firefox-main/source/dom/media/webrtc/tests>`__
+   * - :searchfox:`dom/media/webrtc/tests`
      - Tests
      - This contains `some` of the WebRTC related tests
      -
-   * - `dom/media/webrtc/third_party_build <https://searchfox.org/firefox-main/source/dom/media/webrtc/third_party_build>`__
+   * - :searchfox:`dom/media/webrtc/third_party_build`
      - Build
      - The scripting and configuration for vendoring new versions of libwebrtc are here
      - This is unlikely to be of concern for debugging
-   * - `dom/media/webrtc/transport <https://searchfox.org/firefox-main/source/dom/media/webrtc/transport>`__
+   * - :searchfox:`dom/media/webrtc/transport`
      - Network
      - This contains the ICE implementation, the MDNS implementation, and transport code
      -
-   * - `dom/media/webrtc/transport/ipc <https://searchfox.org/firefox-main/source/dom/media/webrtc/transport/ipc>`__
+   * - :searchfox:`dom/media/webrtc/transport/ipc`
      - Network
      - IPDL protocols for WebRTC transport, including STUN address requests and WebRTC TCP sockets
      -
-   * - `dom/media/webrtc/transportbridge <https://searchfox.org/firefox-main/source/dom/media/webrtc/transportbridge>`__
+   * - :searchfox:`dom/media/webrtc/transportbridge`
      - WebRTC
      - This contains the MediaPipeline and MediaPipeline filter code which is glue between transport and the libwebrtc RTP stack
      -
-   * - `third_party/libsrtp <https://searchfox.org/firefox-main/source/third_party/libsrtp>`__
+   * - :searchfox:`third_party/libsrtp`
      - Network
      - This is the SRTP implementation used by Firefox
      -
-   * - `third_party/libwebrtc <https://searchfox.org/firefox-main/source/third_party/libwebrtc>`__
+   * - :searchfox:`third_party/libwebrtc`
      - WebRTC (various)
      - libwebrtc handles many aspects of WebRTC calls above the transport layer and below the presentation layer
      -
-   * - `third_party/rust/webrtc-sdp <https://searchfox.org/firefox-main/source/third_party/rust/webrtc-sdp>`__
+   * - :searchfox:`third_party/rust/webrtc-sdp`
      - Signalling
      - webrtc-sdp is a Rust implementation of a WebRTC-only SDP parser
      -
-   * - `third_party/sipcc <https://searchfox.org/firefox-main/source/third_party/sipcc>`__
+   * - :searchfox:`third_party/sipcc`
      - Signalling
      - sipcc is a C implementation of a general SDP parser
      - this carries many local modifications
-   * - `dom/media <https://searchfox.org/firefox-main/source/dom/media>`__
+   * - :searchfox:`dom/media`
      - Media Capture
      - GetUserMedia and related classes are here
      - There are many other unrelated media source files here
-   * - `dom/media/systemservices <https://searchfox.org/firefox-main/source/dom/media/systemservices>`__
+   * - :searchfox:`dom/media/systemservices`
      - Media Capture
      - System services for media capture including camera/microphone access
      - Contains CamerasChild, CamerasParent, VideoEngine, and platform-specific implementations
-   * - `dom/media/encoder <https://searchfox.org/firefox-main/source/dom/media/encoder>`__
+   * - :searchfox:`dom/media/encoder`
      - Media Encoding
      - Media encoders for recording, including Opus and VP8 track encoders
      -
-   * - `dom/media/gmp <https://searchfox.org/firefox-main/source/dom/media/gmp>`__
+   * - :searchfox:`dom/media/gmp`
      - Media Codecs
      - Gecko Media Plugin (GMP) framework for sandboxed codec plugins
      - Used by WebRTC for H.264 codec support
-   * - `dom/media/platforms <https://searchfox.org/firefox-main/source/dom/media/platforms>`__
+   * - :searchfox:`dom/media/platforms`
      - Media Codecs
      - Platform-specific encoder/decoder implementations (Apple, Android, FFmpeg, WMF)
      - Contains PlatformEncoderModule and EncoderConfig used by WebRTC
-   * - `netwerk/sctp/datachannel <https://searchfox.org/firefox-main/source/netwerk/sctp/datachannel>`__
+   * - :searchfox:`netwerk/sctp/datachannel`
      - Data Channels
      - SCTP-based data channel implementation
      -
-   * - `browser/components/webrtc <https://searchfox.org/firefox-main/source/browser/components/webrtc>`__
+   * - :searchfox:`browser/components/webrtc`
      - Browser UI
      - Browser-level WebRTC UI components including permission prompts and indicators
      -
-   * - `toolkit/content/aboutwebrtc <https://searchfox.org/firefox-main/source/toolkit/content/aboutwebrtc>`__
+   * - :searchfox:`toolkit/content/aboutwebrtc`
      - Debugging
      - Implementation of the about:webrtc debugging page
      -
-   * - `media/webrtc/signaling <https://searchfox.org/firefox-main/source/media/webrtc/signaling>`__
+   * - :searchfox:`media/webrtc/signaling`
      - Signalling
      - WebRTC signaling implementation and GTests
      -
-   * - `browser/base/content/test/webrtc <https://searchfox.org/firefox-main/source/browser/base/content/test/webrtc>`__
+   * - :searchfox:`browser/base/content/test/webrtc`
      - Tests
      - Browser chrome tests for WebRTC getUserMedia and getDisplayMedia
      -
-   * - `testing/web-platform/tests/webrtc <https://searchfox.org/firefox-main/source/testing/web-platform/tests/webrtc>`__
+   * - :searchfox:`testing/web-platform/tests/webrtc`
      - Tests
      - Web Platform Tests for WebRTC conformance
      - Also includes webrtc-encoded-transform, webrtc-extensions, webrtc-ice, webrtc-identity, webrtc-priority, webrtc-stats, webrtc-svc
-   * - `dom/webidl <https://searchfox.org/firefox-main/source/dom/webidl>`__
+   * - :searchfox:`dom/webidl`
      - WebIDL (JS API)
      - This contains the WebIDL definitions for the WebRTC JS API amongst many other WebIDL definitions
      -  :code:`RTC*.webidl`
diff --git a/docs/contributing/editors/vscode.rst b/docs/contributing/editors/vscode.rst
index bbebbc72fad1..98f47ce1b6e9 100644
--- a/docs/contributing/editors/vscode.rst
+++ b/docs/contributing/editors/vscode.rst
@@ -22,7 +22,7 @@ Firefox source tree comes with its own set of recommendations of Visual Studio
 Code extensions. They will be offered when you first open the project.
 
 If you need to refer to them later, the extensions are listed in
-`.vscode/extensions.json <https://searchfox.org/firefox-main/source/.vscode/extensions.json>`__.
+:searchfox:`.vscode/extensions.json`.
 
 For Rust development, the `rust-analyzer <https://marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer>`__ extension is recommended.
 `See the manual <https://rust-analyzer.github.io/manual.html>`__ for more information.
diff --git a/docs/jsloader/jsloader-api.rst b/docs/jsloader/jsloader-api.rst
index 8d4db8407840..e328cd0bf409 100644
--- a/docs/jsloader/jsloader-api.rst
+++ b/docs/jsloader/jsloader-api.rst
@@ -20,7 +20,7 @@ global variables are defined into the given object.
       "chrome://browser/content/browser.js", this
     );
 
-See `mozIJSSubScriptLoader.idl <https://searchfox.org/firefox-main/source/js/xpconnect/idl/mozIJSSubScriptLoader.idl>`_ for more details
+See :searchfox:`mozIJSSubScriptLoader.idl <js/xpconnect/idl/mozIJSSubScriptLoader.idl>` for more details
 
 Asynchronous Classic Script Compile
 -----------------------------------
@@ -41,7 +41,7 @@ classic script, and execute in given globals.
       const result2 = script.executeInGlobal(targetGlobal2);
     }
 
-See `ChromeUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/ChromeUtils.webidl>`_ and `PrecompiledScript.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/PrecompiledScript.webidl>`_ for more details.
+See :searchfox:`ChromeUtils.webidl <dom/chrome-webidl/ChromeUtils.webidl>` and :searchfox:`PrecompiledScript.webidl <dom/chrome-webidl/PrecompiledScript.webidl>` for more details.
 
 Synchronous Module Import
 -------------------------
diff --git a/docs/jsloader/system-modules.rst b/docs/jsloader/system-modules.rst
index fd8789d7c074..3da2404cbc73 100644
--- a/docs/jsloader/system-modules.rst
+++ b/docs/jsloader/system-modules.rst
@@ -16,7 +16,7 @@ modules.
 All system modules are imported into the shared system global (except for
 modules loaded into the `DevTools distinct system global`_).
 
-See ``mozJSModuleLoader::CreateLoaderGlobal`` in `mozJSModuleLoader.cpp <https://searchfox.org/firefox-main/source/js/xpconnect/loader/mozJSModuleLoader.cpp>`_ for details about the global and built-in functions.
+See ``mozJSModuleLoader::CreateLoaderGlobal`` in :searchfox:`mozJSModuleLoader.cpp <js/xpconnect/loader/mozJSModuleLoader.cpp>` for details about the global and built-in functions.
 
 Defining a Module
 -----------------
@@ -145,7 +145,7 @@ property with the symbol name and the module URI for each.
       TestFunc: "resource://gre/modules/Test.sys.mjs",
     });
 
-See `ChromeUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/ChromeUtils.webidl>`_ for more details.
+See :searchfox:`ChromeUtils.webidl <dom/chrome-webidl/ChromeUtils.webidl>` for more details.
 
 Using the Namespace Object
 --------------------------
@@ -226,7 +226,7 @@ The exported object should follow the specified XPCOM interface.
     nsCOMPtr<nsIUtils> utils = do_ImportESModule(
       "resource://gre/modules/Test.sys.mjs", "Utils");
 
-See `nsImportModule.h <https://searchfox.org/firefox-main/source/js/xpconnect/loader/nsImportModule.h>`_ for more details.
+See :searchfox:`nsImportModule.h <js/xpconnect/loader/nsImportModule.h>` for more details.
 
 Lifetime
 --------
@@ -301,7 +301,7 @@ This is only for the debugging purpose.
     console.log(
       Cu.getModuleImportStack("resource://gre/modules/Test.sys.mjs"));
 
-See `xpccomponents.idl <https://searchfox.org/firefox-main/source/js/xpconnect/idl/xpccomponents.idl>`_ for more details.
+See :searchfox:`xpccomponents.idl <js/xpconnect/idl/xpccomponents.idl>` for more details.
 
 Limitations
 -----------
@@ -347,7 +347,7 @@ used.  The module is imported into the DevTools distinct system global if the
 current global is the DevTools distinct system global.  Otherwise the module
 is imported into the shared system global.
 
-See ``ImportESModuleTargetGlobal`` in `ChromeUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/ChromeUtils.webidl>`_ for more details.
+See ``ImportESModuleTargetGlobal`` in :searchfox:`ChromeUtils.webidl <dom/chrome-webidl/ChromeUtils.webidl>` for more details.
 
 Integration with JSActors
 -------------------------
diff --git a/docs/nspr/reference/pr_extern.rst b/docs/nspr/reference/pr_extern.rst
index efb36b3c6835..c56c6c375072 100644
--- a/docs/nspr/reference/pr_extern.rst
+++ b/docs/nspr/reference/pr_extern.rst
@@ -20,7 +20,7 @@ Description
 
 :ref:`PR_EXTERN` is used to define externally visible routines and globals.
 For syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
 The macro includes the proper specifications to declare the target
 ``extern`` and set up other required linkages.
 
diff --git a/docs/nspr/reference/pr_implement.rst b/docs/nspr/reference/pr_implement.rst
index ecc94bfb34ac..cf4028451ddc 100644
--- a/docs/nspr/reference/pr_implement.rst
+++ b/docs/nspr/reference/pr_implement.rst
@@ -20,7 +20,7 @@ Description
 
 :ref:`PR_IMPLEMENT` is used to define implementations of externally visible
 routines and globals. For syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
 
 .. warning::
 
diff --git a/docs/nspr/reference/prfileinfo.rst b/docs/nspr/reference/prfileinfo.rst
index b025003e9e19..7f2b830679fe 100644
--- a/docs/nspr/reference/prfileinfo.rst
+++ b/docs/nspr/reference/prfileinfo.rst
@@ -35,10 +35,10 @@ The structure has the following fields:
    Size, in bytes, of file's contents.
 ``creationTime``
    Creation time per definition of :ref:`PRTime`. See
-   `prtime.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtime.h>`__.
+   :searchfox:`prtime.h <nsprpub/pr/include/prtime.h>`.
 ``modifyTime``
    Last modification time per definition of :ref:`PRTime`. See
-   `prtime.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtime.h>`__.
+   :searchfox:`prtime.h <nsprpub/pr/include/prtime.h>`.
 
 
 Description
diff --git a/docs/nspr/reference/prfileinfo64.rst b/docs/nspr/reference/prfileinfo64.rst
index 5b73abddb1e7..a1272c09cb33 100644
--- a/docs/nspr/reference/prfileinfo64.rst
+++ b/docs/nspr/reference/prfileinfo64.rst
@@ -33,10 +33,10 @@ The structure has the following fields:
    64-bit size, in bytes, of file's contents.
 ``creationTime``
    Creation time per definition of :ref:`PRTime`. See
-   `prtime.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtime.h>`__.
+   :searchfox:`prtime.h <nsprpub/pr/include/prtime.h>`.
 ``modifyTime``
    Last modification time per definition of :ref:`PRTime`. See
-   `prtime.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtime.h>`__.
+   :searchfox:`prtime.h <nsprpub/pr/include/prtime.h>`.
 
 
 Description
diff --git a/docs/nspr/reference/print32.rst b/docs/nspr/reference/print32.rst
index 9b34a180c212..0c895f430b42 100644
--- a/docs/nspr/reference/print32.rst
+++ b/docs/nspr/reference/print32.rst
@@ -19,4 +19,4 @@ Description
 
 May be defined as an ``int`` or a ``long``, depending on the platform.
 For syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
diff --git a/docs/nspr/reference/print64.rst b/docs/nspr/reference/print64.rst
index 745647bfa76a..73ffc89d1ac1 100644
--- a/docs/nspr/reference/print64.rst
+++ b/docs/nspr/reference/print64.rst
@@ -19,4 +19,4 @@ Description
 
 May be defined in several different ways, depending on the platform. For
 syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
diff --git a/docs/nspr/reference/pruint32.rst b/docs/nspr/reference/pruint32.rst
index 333f7753a92b..259c80d35795 100644
--- a/docs/nspr/reference/pruint32.rst
+++ b/docs/nspr/reference/pruint32.rst
@@ -19,4 +19,4 @@ Description
 
 May be defined as an unsigned ``int`` or an unsigned ``long``, depending
 on the platform. For syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
diff --git a/docs/nspr/reference/pruint64.rst b/docs/nspr/reference/pruint64.rst
index a20ffe497105..0aa06af8c4da 100644
--- a/docs/nspr/reference/pruint64.rst
+++ b/docs/nspr/reference/pruint64.rst
@@ -19,4 +19,4 @@ Description
 
 May be defined in several different ways, depending on the platform. For
 syntax details for each platform, see
-`prtypes.h <https://searchfox.org/firefox-main/source/nsprpub/pr/include/prtypes.h>`__.
+:searchfox:`prtypes.h <nsprpub/pr/include/prtypes.h>`.
diff --git a/docs/overview/gecko.rst b/docs/overview/gecko.rst
index 29a04a234104..dc52ae16cd08 100644
--- a/docs/overview/gecko.rst
+++ b/docs/overview/gecko.rst
@@ -211,10 +211,10 @@ Firefox captures the security context using one of the following four types of P
   in Firefox Extensions.
 
 Whenever Firefox starts to load a resource (e.g. script, css, image) then security relevant meta
-information including `nsIPrincipal <https://searchfox.org/firefox-main/source/caps/nsIPrincipal.idl>`_
-is attached to the `nsILoadInfo <https://searchfox.org/firefox-main/source/netwerk/base/nsILoadInfo.idl>`_.
+information including :searchfox:`nsIPrincipal <caps/nsIPrincipal.idl>`
+is attached to the :searchfox:`nsILoadInfo <netwerk/base/nsILoadInfo.idl>`.
 This load context providing object remains attached to the resource load (
-`nsIChannel <https://searchfox.org/firefox-main/source/netwerk/base/nsIChannel.idl>`_) throughout
+:searchfox:`nsIChannel <netwerk/base/nsIChannel.idl>`) throughout
 the entire loading life cycle of a resource and allows Firefox to provide the same security
 guarantees even if the resource load encounters a server side redirect.
 
@@ -254,8 +254,8 @@ The ``about`` protocol allows for binding short human-readable urls to internal
 displayed in the content area. For the most part each about page is simply a simpler name for
 content in the chrome or resource protocols. For example the page ``about:processes`` simply loads
 ``chrome://global/content/aboutProcesses.html``. About pages are registered in the
-`global <https://searchfox.org/firefox-main/source/docshell/base/nsAboutRedirector.cpp>`_ and
-`desktop <https://searchfox.org/firefox-main/source/browser/components/about/AboutRedirector.cpp>`_
+:searchfox:`global <docshell/base/nsAboutRedirector.cpp>` and
+:searchfox:`desktop <browser/components/about/AboutRedirector.cpp>`
 redirector components.
 
 Toolkit
diff --git a/docs/setup/building_with_debug_symbols.rst b/docs/setup/building_with_debug_symbols.rst
index 76b65cc089cd..8ecb18290c18 100644
--- a/docs/setup/building_with_debug_symbols.rst
+++ b/docs/setup/building_with_debug_symbols.rst
@@ -44,7 +44,7 @@ archive of :ref:`Breakpad <Crash reporting>` symbol files:
 
 Treeherder uses an additional ``uploadsymbols`` target to upload
 symbols to a socorro server. See
-https://searchfox.org/firefox-main/source/toolkit/crashreporter/tools/upload_symbols.py
+:searchfox:`toolkit/crashreporter/tools/upload_symbols.py`
 for more information about the environment variables used by this
 target.
 
diff --git a/docs/setup/macos_build.rst b/docs/setup/macos_build.rst
index b6778c22e165..816b52fe594a 100644
--- a/docs/setup/macos_build.rst
+++ b/docs/setup/macos_build.rst
@@ -149,7 +149,7 @@ Building, running, testing, etc. not always support the latest Python versions,
 especially after updating your Python distribution to a new version.
 
 The recommended way to work around this is to use a virtual environment with a compatible Python version.
-Please consider `mach's <https://searchfox.org/firefox-main/source/mach>`_ ``MIN_PYTHON_VERSION`` and ``MAX_PYTHON_VERSION_TO_CONSIDER``
+Please consider :searchfox:`mach's <mach>` ``MIN_PYTHON_VERSION`` and ``MAX_PYTHON_VERSION_TO_CONSIDER``
 for the range of compatible versions.
 
 Should you be using Python through Homebrew, you can install older releases like this:
diff --git a/dom/docs/ipc/jsactors.rst b/dom/docs/ipc/jsactors.rst
index 8814d175685d..2d866183b13c 100644
--- a/dom/docs/ipc/jsactors.rst
+++ b/dom/docs/ipc/jsactors.rst
@@ -261,7 +261,7 @@ The outer window for the frame associated with this ``JSWindowActorChild``.
 
 The ``nsIDocShell`` for the frame associated with this ``JSWindowActorChild``.
 
-See `JSWindowActor.webidl`_ for more detail on exactly what is exposed on both ``JSWindowActorParent`` and ``JSWindowActorChild`` implementations.
+See :searchfox:`JSWindowActor.webidl <dom/chrome-webidl/JSWindowActor.webidl>` for more detail on exactly what is exposed on both ``JSWindowActorParent`` and ``JSWindowActorChild`` implementations.
 
 How to port from message manager and framescripts to JSWindowActors
 -------------------------------------------------------------------
@@ -385,8 +385,8 @@ In the ``JS*ACTORS`` objects, each key is the name of the actor pair (example: `
 
 The full list of registration parameters can be found:
 
-- for JSProcessActor in file `JSProcessActor.webidl`_ as ``WindowActorOptions``, ``ProcessActorSidedOptions`` and ``ProcessActorChildOptions``.
-- for JSWindowActor in file `JSWindowActor.webidl`_ as ``WindowActorOptions``, ``WindowActorSidedOptions`` and ``WindowActorChildOptions``.
+- for JSProcessActor in file :searchfox:`JSProcessActor.webidl <dom/chrome-webidl/JSProcessActor.webidl>` as ``WindowActorOptions``, ``ProcessActorSidedOptions`` and ``ProcessActorChildOptions``.
+- for JSWindowActor in file :searchfox:`JSWindowActor.webidl <dom/chrome-webidl/JSWindowActor.webidl>` as ``WindowActorOptions``, ``WindowActorSidedOptions`` and ``WindowActorChildOptions``.
 
 Here's an example ``JSWindowActor`` registration pulled from ``BrowserGlue.sys.mjs``:
 
@@ -540,7 +540,5 @@ And more
 .. _Electrolysis Project: https://wiki.mozilla.org/Electrolysis
 .. _IPC Actors: https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial
 .. _Context Menu Fission Port: https://hg.mozilla.org/mozilla-central/rev/adc60720b7b8
-.. _JSProcessActor.webidl: https://searchfox.org/firefox-main/source/dom/chrome-webidl/JSProcessActor.webidl
-.. _JSWindowActor.webidl: https://searchfox.org/firefox-main/source/dom/chrome-webidl/JSWindowActor.webidl
-.. _BrowserElementParent.sys.mjs: https://searchfox.org/firefox-main/source/toolkit/actors/BrowserElementParent.sys.mjs
+.. _BrowserElementParent.sys.mjs: :searchfox:`toolkit/actors/BrowserElementParent.sys.mjs`
 .. _Transferable: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects
diff --git a/dom/docs/ipc/process_model.rst b/dom/docs/ipc/process_model.rst
index f324e8b072a5..b69a1c7d373f 100644
--- a/dom/docs/ipc/process_model.rst
+++ b/dom/docs/ipc/process_model.rst
@@ -1,7 +1,7 @@
 Process Model
 =============
 
-The complete set of recognized process types is defined in `GeckoProcessTypes <https://searchfox.org/firefox-main/source/xpcom/geckoprocesstypes_generator/geckoprocesstypes/__init__.py>`_.
+The complete set of recognized process types is defined in :searchfox:`GeckoProcessTypes <xpcom/geckoprocesstypes_generator/geckoprocesstypes/__init__.py>`.
 
 For more details on how process types are added and managed by IPC, see the process creation documentation :ref:`Gecko Processes`.
 
@@ -94,13 +94,13 @@ As the parent process can display HTML and JS, such as the browser UI and privil
 Content Process
 ---------------
 
-:primary protocol: `PContent <https://searchfox.org/firefox-main/source/dom/ipc/PContent.ipdl>`_
+:primary protocol: :searchfox:`PContent <dom/ipc/PContent.ipdl>`
 :other names: Renderer Process
 :sandboxed?: yes (content sandbox policy)
 
 Content processes are used to load web content, and are the only process type (other than the parent process) which can load and execute JS code. These processes are further subdivided into specific "remote types", which specify the type of content loaded within them, their sandboxing behavior, and can gate access to certain privileged IPC methods.
 
-The specific remote type and isolation behaviour used for a specific resource is currently controlled in 2 major places. When performing a document navigation, the final process to load the document in is selected by the logic in `ProcessIsolation.cpp <https://searchfox.org/firefox-main/source/dom/ipc/ProcessIsolation.cpp>`_. This will combine information about the specific response, such as the site and headers, with other state to select which process and other isolating actions should be taken. When selecting which process to create the initial process for a new tab in, and when selecting processes for serviceworkers and shared workers, the logic in :searchfox:`E10SUtils.sys.mjs <toolkit/modules/E10SUtils.sys.mjs>` is used to select a process. The logic in ``E10SUtils.sys.mjs`` will likely be removed and replaced with ``ProcessIsolation.cpp`` in the future.
+The specific remote type and isolation behaviour used for a specific resource is currently controlled in 2 major places. When performing a document navigation, the final process to load the document in is selected by the logic in :searchfox:`ProcessIsolation.cpp <dom/ipc/ProcessIsolation.cpp>`. This will combine information about the specific response, such as the site and headers, with other state to select which process and other isolating actions should be taken. When selecting which process to create the initial process for a new tab in, and when selecting processes for serviceworkers and shared workers, the logic in :searchfox:`E10SUtils.sys.mjs <toolkit/modules/E10SUtils.sys.mjs>` is used to select a process. The logic in ``E10SUtils.sys.mjs`` will likely be removed and replaced with ``ProcessIsolation.cpp`` in the future.
 
 .. note::
 
@@ -232,7 +232,7 @@ ServiceWorker web content processes are used to host ServiceWorkers on a per-sit
 Gecko Media Plugins (GMP) Process
 ---------------------------------
 
-:primary protocol: `PGMP <https://searchfox.org/firefox-main/source/dom/media/gmp/PGMP.ipdl>`_
+:primary protocol: :searchfox:`PGMP <dom/media/gmp/PGMP.ipdl>`
 :sandboxed?: yes (GMP sandbox policy)
 
 The GMP process is used to sandbox third-party "Content Decryption Module" (CDM) binaries used for media playback in a sandboxed environment. This process is only launched when DRM-enabled content is loaded.
@@ -242,7 +242,7 @@ The GMP process is used to sandbox third-party "Content Decryption Module" (CDM)
 GPU Process
 -----------
 
-:primary protocol: `PGPU <https://searchfox.org/firefox-main/source/gfx/ipc/PGPU.ipdl>`_
+:primary protocol: :searchfox:`PGPU <gfx/ipc/PGPU.ipdl>`
 :other names: Compositor Process
 :sandboxed?: no (`bug 1347710 <https://bugzilla.mozilla.org/show_bug.cgi?id=1347710>`_ tracks sandboxing on windows)
 
@@ -255,7 +255,7 @@ The GPU process is not used on all platforms. Platforms which do not use it, suc
 VR Process
 ----------
 
-:primary protocol: `PVR <https://searchfox.org/firefox-main/source/gfx/vr/ipc/PVR.ipdl>`_
+:primary protocol: :searchfox:`PVR <gfx/vr/ipc/PVR.ipdl>`
 :sandboxed?: no (`bug 1430043 <https://bugzilla.mozilla.org/show_bug.cgi?id=1430043>`_ tracks sandboxing on windows)
 
 VR headset libraries require access to specific OS level features and other requirements which we would generally like to block with the sandbox in other processes. In order to allow the GPU process to have tighter sandboxing rules, these VR libraries are loaded into the less-restricted VR process. Like the GPU process, this serves to isolate them from the rest of Firefox and reduce the impact of bugs in these libraries on the rest of the browser. The VR process is launched only after a user visits a site which uses WebVR.
@@ -265,7 +265,7 @@ VR headset libraries require access to specific OS level features and other requ
 Data Decoder (RDD) Process
 --------------------------
 
-:primary protocol: `PRDD <https://searchfox.org/firefox-main/source/dom/media/ipc/PRDD.ipdl>`_
+:primary protocol: :searchfox:`PRDD <dom/media/ipc/PRDD.ipdl>`
 :sandboxed?: yes (RDD sandbox policy)
 
 This process is used to run media data decoders within their own sandboxed process, allowing the code to be isolated from other code in Gecko. This aims to reduce the severity of potential bugs in media decoder libraries, and improve the security of the browser.
@@ -285,7 +285,7 @@ This process is used to run media data decoders within their own sandboxed proce
 Network (Socket) Process
 ------------------------
 
-:primary protocol: `PSocketProcess <https://searchfox.org/firefox-main/source/netwerk/ipc/PSocketProcess.ipdl>`_
+:primary protocol: :searchfox:`PSocketProcess <netwerk/ipc/PSocketProcess.ipdl>`
 :sandboxed?: yes (socket sandbox policy)
 
 The socket process is used to separate certain networking operations from the parent process, allowing them to be performed more directly in a partially sandboxed process. The eventual goal is to move all TCP/UDP network operations into this dedicated process, and is being tracked in `Bug 1322426 <https://bugzilla.mozilla.org/show_bug.cgi?id=1322426>`_.
@@ -327,7 +327,7 @@ This test-only process type is intended for use when writing IPDL unit tests. Ho
 Utility Process
 ---------------
 
-:primary protocol: `PUtilityProcess <https://searchfox.org/firefox-main/source/ipc/glue/PUtilityProcess.ipdl>`_
+:primary protocol: :searchfox:`PUtilityProcess <ipc/glue/PUtilityProcess.ipdl>`
 :metabug: `Bug 1722051 <https://bugzilla.mozilla.org/show_bug.cgi?id=1722051>`_
 :sandboxed?: yes, customizable
 
diff --git a/dom/docs/navigation/BrowsingContext.rst b/dom/docs/navigation/BrowsingContext.rst
index 890e552f39b4..0a7bd8b7672d 100644
--- a/dom/docs/navigation/BrowsingContext.rst
+++ b/dom/docs/navigation/BrowsingContext.rst
@@ -77,8 +77,8 @@ API Documentation
   .. hlist::
     :columns: 3
 
-    * `header (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/BrowsingContext.h>`__
-    * `source (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/BrowsingContext.cpp>`__
+    * :searchfox:`header (searchfox) <docshell/base/BrowsingContext.h>`
+    * :searchfox:`source (searchfox) <docshell/base/BrowsingContext.cpp>`
     * `html spec <https://html.spec.whatwg.org/multipage/browsers.html#browsing-context>`_
 
   This is a synced-context type. Instances of it will exist in every
@@ -115,8 +115,8 @@ API Documentation
   .. hlist::
     :columns: 3
 
-    * `header (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/CanonicalBrowsingContext.h>`__
-    * `source (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/CanonicalBrowsingContext.cpp>`__
+    * :searchfox:`header (searchfox) <docshell/base/CanonicalBrowsingContext.h>`
+    * :searchfox:`source (searchfox) <docshell/base/CanonicalBrowsingContext.cpp>`
 
   When a :cpp:class:`BrowsingContext` is constructed in the parent process,
   it is actually an instance of :cpp:class:`CanonicalBrowsingContext`.
@@ -129,21 +129,21 @@ API Documentation
   .. hlist::
     :columns: 3
 
-    * `header (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/WindowContext.h>`__
-    * `source (searchfox) <https://searchfox.org/firefox-main/source/docshell/base/WindowContext.cpp>`__
+    * :searchfox:`header (searchfox) <docshell/base/WindowContext.h>`
+    * :searchfox:`source (searchfox) <docshell/base/WindowContext.cpp>`
 
 .. cpp:class:: WindowGlobalParent : public WindowContext, public WindowGlobalActor, public PWindowGlobalParent
 
   .. hlist::
     :columns: 3
 
-    * `header (searchfox) <https://searchfox.org/firefox-main/source/dom/ipc/WindowGlobalParent.h>`__
-    * `source (searchfox) <https://searchfox.org/firefox-main/source/dom/ipc/WindowGlobalParent.cpp>`__
+    * :searchfox:`header (searchfox) <dom/ipc/WindowGlobalParent.h>`
+    * :searchfox:`source (searchfox) <dom/ipc/WindowGlobalParent.cpp>`
 
 .. cpp:class:: WindowGlobalChild : public WindowGlobalActor, public PWindowGlobalChild
 
   .. hlist::
     :columns: 3
 
-    * `header (searchfox) <https://searchfox.org/firefox-main/source/dom/ipc/WindowGlobalChild.h>`__
-    * `source (searchfox) <https://searchfox.org/firefox-main/source/dom/ipc/WindowGlobalChild.cpp>`__
+    * :searchfox:`header (searchfox) <dom/ipc/WindowGlobalChild.h>`
+    * :searchfox:`source (searchfox) <dom/ipc/WindowGlobalChild.cpp>`
diff --git a/dom/docs/workersAndStorage/CodeStyle.rst b/dom/docs/workersAndStorage/CodeStyle.rst
index ef5e6e13b57c..85a8f55d135c 100644
--- a/dom/docs/workersAndStorage/CodeStyle.rst
+++ b/dom/docs/workersAndStorage/CodeStyle.rst
@@ -199,7 +199,7 @@ In function signatures, prefer accepting or returning ``RefPtr`` instead of
 ``already_AddRefed`` in conjunction with regular ``std::move`` rather than
 ``.forget()``. This improves readability and code generation. Prevailing
 legimitate uses of ``already_AddRefed`` are described in its
-`documentation <https://searchfox.org/mozilla-central/rev/4df8821c1b824db5f40f381f48432f219d99ae36/mfbt/AlreadyAddRefed.h#31>`_.
+:searchfox:`documentation <mozilla-central/rev/4df8821c1b824db5f40f381f48432f219d99ae36:mfbt/AlreadyAddRefed.h#31>`.
 
 Prefer using ``mozilla::UniquePtr`` over ``nsAutoPtr``, since the latter is
 deprecated (and e.g. has no factory function, see Bug 1600079).
diff --git a/dom/docs/workersAndStorage/PerformanceTesting.rst b/dom/docs/workersAndStorage/PerformanceTesting.rst
index a930254adcd2..e95dd4d7f075 100644
--- a/dom/docs/workersAndStorage/PerformanceTesting.rst
+++ b/dom/docs/workersAndStorage/PerformanceTesting.rst
@@ -4,8 +4,7 @@ Service Worker Performance Tests
 
 Our performance tests are mochitests running in the `mozperftest
 <https://firefox-source-docs.mozilla.org/testing/perfdocs/mozperftest.html>`_
-harness.  Tests reside under `dom/serviceworkers/test/performance
-<https://searchfox.org/firefox-main/source/dom/serviceworkers/test/performance>`_,
+harness.  Tests reside under :searchfox:`dom/serviceworkers/test/performance`,
 itemized in perftest.toml.  Beyond the standard mochitest machinery,
 performance tests define a ``perfMetadata`` variable at the top level, and call:
 
@@ -23,18 +22,14 @@ They can be run via mach perftest, or as normal mochitests via mach test.
 Adding new tests
 ================
 
-Add files to `perftest.toml
-<https://searchfox.org/firefox-main/source/dom/serviceworkers/test/performance/perftest.toml>`_
+Add files to :searchfox:`perftest.toml <dom/serviceworkers/test/performance/perftest.toml>`
 as usual for mochitests.
 
-Modify linux.yml, macosx.yml, and windows11.yml under `taskcluster/kinds/perftest
-<https://searchfox.org/firefox-main/source/taskcluster/kinds/perftest>`_.
-Currently, each test needs to be added individually to the run command (`here
-<https://searchfox.org/mozilla-central/rev/91cc8848427fdbbeb324e6ca56a0d08d32d3c308/taskcluster/ci/perftest/linux.yml#121-149>`_,
+Modify linux.yml, macosx.yml, and windows11.yml under :searchfox:`taskcluster/kinds/perftest`.
+Currently, each test needs to be added individually to the run command (:searchfox:`here <mozilla-central/rev/91cc8848427fdbbeb324e6ca56a0d08d32d3c308:taskcluster/ci/perftest/linux.yml#121-149>`,
 for example).  kind.yml can be ignored–it provides some defaults.
 
-Add your new test to `perfdocs/config.yml
-<https://searchfox.org/firefox-main/source/python/mozperftest/perfdocs/config.yml>`_.
+Add your new test to :searchfox:`perfdocs/config.yml <python/mozperftest/perfdocs/config.yml>`.
 
 Modify the generated documentation using:
 
diff --git a/editor/docs/IMEHandlingGuide.rst b/editor/docs/IMEHandlingGuide.rst
index 6d2c24a96538..0b222f8c44a2 100644
--- a/editor/docs/IMEHandlingGuide.rst
+++ b/editor/docs/IMEHandlingGuide.rst
@@ -82,31 +82,40 @@ selections from ``mozilla::TextRangeType`` which are sent by
 ``mozilla::WidgetCompositionEvent`` as ``mozilla::TextRangeArray``. The
 following table explains the mapping between them.
 
-.. table:: Selection types of each clause of composition string or caret
+.. list-table:: Selection types of each clause of composition string or caret
+   :header-rows: 1
+   :widths: auto
 
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
-   |                                                            |`nsISelectionController`_              |`mozilla::SelectionType`_|`mozilla::TextRangeType`_|
-   +============================================================+=======================================+=========================+=========================+
-   |Caret                                                       |``SELECTION_NORMAL``                   |``eNormal``              |``eCaret``               |
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
-   |Raw text typed by the user                                  |``SELECTION_IME_RAW_INPUT``            |``eIMERawClause``        |``eRawClause``           |
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
-   |Selected clause of raw text typed by the user               |``SELECTION_IME_SELECTEDRAWTEXT``      |``eIMESelectedRawClause``|``eSelectedRawClause``   |
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
-   |Converted clause by IME                                     |``SELECTION_IME_CONVERTEDTEXT``        |``eIMEConvertedClause``  |``eConvertedClause``     |
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
-   |Selected clause by the user or IME and also converted by IME|``SELECTION_IME_SELECTEDCONVERTEDTEXT``|``eIMESelectedClause``   |``eSelectedClause``      |
-   +------------------------------------------------------------+---------------------------------------+-------------------------+-------------------------+
+   * -
+     - :searchfox:`nsISelectionController <dom/base/nsISelectionController.idl>`
+     - :searchfox:`mozilla::SelectionType <dom/base/nsISelectionController.idl>`
+     - :searchfox:`mozilla::TextRangeType <widget/TextRange.h>`
+   * - Caret
+     - ``SELECTION_NORMAL``
+     - ``eNormal``
+     - ``eCaret``
+   * - Raw text typed by the user
+     - ``SELECTION_IME_RAW_INPUT``
+     - ``eIMERawClause``
+     - ``eRawClause``
+   * - Selected clause of raw text typed by the user
+     - ``SELECTION_IME_SELECTEDRAWTEXT``
+     - ``eIMESelectedRawClause``
+     - ``eSelectedRawClause``
+   * - Converted clause by IME
+     - ``SELECTION_IME_CONVERTEDTEXT``
+     - ``eIMEConvertedClause``
+     - ``eConvertedClause``
+   * - Selected clause by the user or IME and also converted by IME
+     - ``SELECTION_IME_SELECTEDCONVERTEDTEXT``
+     - ``eIMESelectedClause``
+     - ``eSelectedClause``
 
 Note that typically, "Selected clause of raw text typed by the user" isn't used
 because when composition string is already separated to multiple clauses, that
 means that the composition string has already been converted by IME at least
 once.
 
-.. _nsISelectionController: https://searchfox.org/firefox-main/source/dom/base/nsISelectionController.idl
-.. _mozilla::SelectionType: https://searchfox.org/firefox-main/source/dom/base/nsISelectionController.idl
-.. _mozilla::TextRangeType: https://searchfox.org/firefox-main/source/widget/TextRange.h
-
 Modules handling IME composition
 ================================
 
@@ -277,12 +286,12 @@ composition to IME is perefored synchronously. See
 editor/libeditor
 ----------------
 
-`mozilla::EditorEventListener <https://searchfox.org/firefox-main/source/editor/libeditor/EditorEventListener.cpp>`__
+:searchfox:`mozilla::EditorEventListener <editor/libeditor/EditorEventListener.cpp>`
 listens for trusted DOM ``compositionstart``, ``text`` and ``compositionend``
 events and notifies
-`mozilla::EditorBase <https://searchfox.org/firefox-main/source/editor/libeditor/EditorBase.cpp>`__
+:searchfox:`mozilla::EditorBase <editor/libeditor/EditorBase.cpp>`
 and
-`mozilla::TextEditor <https://searchfox.org/firefox-main/source/editor/libeditor/TextEditor.cpp>`__
+:searchfox:`mozilla::TextEditor <editor/libeditor/TextEditor.cpp>`
 of the events.
 
 When ``EditorBase`` receives an ``eCompositionStart``
@@ -291,7 +300,7 @@ instance and stores it.
 
 When ``TextEditor`` receives an ``eCompositionChange`` (DOM ``"text"``) event,
 it creates or modifies a text node which includes the composition string and
-`mozilla::CompositionTransaction <https://searchfox.org/firefox-main/source/editor/libeditor/CompositionTransaction.cpp>`__
+:searchfox:`mozilla::CompositionTransaction <editor/libeditor/CompositionTransaction.cpp>`
 (it was called ``IMETextTxn``) sets IME selections for representing the clauses
 of the composition string.
 
@@ -413,7 +422,7 @@ mozilla::ContentCacheInChild
 ----------------------------
 
 This exists only in remote processes. This is created as a member of
-`PuppetWidget <https://searchfox.org/firefox-main/source/widget/PuppetWidget.cpp>`__.
+:searchfox:`PuppetWidget <widget/PuppetWidget.cpp>`.
 When ``PuppetWidget`` receives notifications to IME from ``IMEContentObserver``
 in the remote process, it makes this class modify its cached content. Then,
 this class do that with ``WidgetQueryContentEvents``. Finally, ``PuppetWidget``
@@ -488,7 +497,7 @@ Style of each clause
 --------------------
 
 The style of each IME selection is managed by
-`LookAndFeel <https://searchfox.org/firefox-main/source/widget/LookAndFeel.h>`__
+:searchfox:`LookAndFeel <widget/LookAndFeel.h>`
 class per platform. Therefore, it can be overridden by prefs.
 
 Background color, foreground color (text color) and underline color can be
@@ -510,7 +519,7 @@ specified with following prefs. The values must be string of "#rrggbb" format.
 Underline style can be specified with the following prefs. The values are
 integer,  0: none, 1: dotted, 2: dashed, 3: solid, 4: double, 5: wavy (The
 values same as ``mozilla::StyleTextDecorationStyle`` defined in
-`nsStyleConsts.h <https://searchfox.org/firefox-main/source/layout/style/nsStyleConsts.h>`__).
+:searchfox:`nsStyleConsts.h <layout/style/nsStyleConsts.h>`).
 
 * ``ui.IMERawInputUnderlineStyle``
 * ``ui.IMESelectedRawTextUnderlineStyle``
@@ -524,7 +533,7 @@ normal width, 200 means double width.
 On some platforms, IME may support its own style for each clause. Currently,
 this feature is supported in TSF mode of Windows and on Linux. The style
 information is stored in ``TextRangeStyle`` which is defined in
-`TextRange.h <https://searchfox.org/firefox-main/source/widget/TextRange.h>`__.
+:searchfox:`TextRange.h <widget/TextRange.h>`.
 It's a member of ``TextRange``. ``TextRange`` is stored in ``mRanges`` of
 ``WidgetCompositionEvent`` only when its message is ``eCompositionChange``.
 
@@ -707,7 +716,7 @@ focused editor, this is sent to widget. But this is sent only when result of
 ``nsIWidget::GetIMEUpdatePreference()`` includes
 ``NOTIFY_MOUSE_BUTTON_EVENT_ON_CHAR``. This is sent with various information.
 See ``IMENotification::mMouseButtonEventData`` in
-`IMEData.h <https://searchfox.org/firefox-main/source/widget/IMEData.h>`__
+:searchfox:`IMEData.h <widget/IMEData.h>`
 for the detail.
 
 If native IME supports mouse button event handling, ``widget`` should notify
@@ -842,7 +851,7 @@ of the new focused node (calls ``IMEStateManager::OnChangeFocus()``).
 returns the result.
 
 Next, ``IMEStateManager`` initializes ``InputContext`` (defined in
-`IMEData.h <https://searchfox.org/firefox-main/source/widget/IMEData.h>`__)
+:searchfox:`IMEData.h <widget/IMEData.h>`)
 with the desired IME state and node information. Then, it calls
 ``nsIWidget::SetInputContext()`` with the ``InputContext``.
 
@@ -917,26 +926,26 @@ How does Gecko disable IME in IMM mode on Windows
 
 Every window on Windows is associated an ``IMContext``. When Gecko disables
 IME,
-`mozilla::widget::IMEHandler <https://searchfox.org/firefox-main/source/widget/windows/WinIMEHandler.cpp>`__::SetInputContext()
+:searchfox:`mozilla::widget::IMEHandler <widget/windows/WinIMEHandler.cpp>`::SetInputContext()
 disassociates the context from the window.
 
 How does Gecko disable IME in TSF mode on Windows
 """""""""""""""""""""""""""""""""""""""""""""""""
 
-`mozilla::widget::TSFTextStore <https://searchfox.org/firefox-main/source/widget/windows/TSFTextStore.cpp>`__
+:searchfox:`mozilla::widget::TSFTextStore <widget/windows/TSFTextStore.cpp>`
 sets focus to a dummy context which disables the keyboard.
 
 How does Gecko disable IME on Mac
 """""""""""""""""""""""""""""""""
 
-`mozilla::widget::TextInputHandler <https://searchfox.org/firefox-main/source/widget/cocoa/TextInputHandler.mm>`__::HandleKeyDownEvent()
+:searchfox:`mozilla::widget::TextInputHandler <widget/cocoa/TextInputHandler.mm>`::HandleKeyDownEvent()
 doesn't call focused view's interpretKeyEvents. This prevents native key events
 to be passed to IME.
 
 How does Gecko disable IME on GTK
 """""""""""""""""""""""""""""""""
 
-`mozilla::widget::IMContextWrapper <https://searchfox.org/firefox-main/source/widget/gtk/IMContextWrapper.cpp>`__
+:searchfox:`mozilla::widget::IMContextWrapper <widget/gtk/IMContextWrapper.cpp>`
 sets focus to a dummy context which doesn't have IME composition.
 
 How does Gecko disable IME on Android
@@ -982,17 +991,16 @@ Following classes handles IME on each platform:
 Windows
 -------
 
-`mozilla::widget::IMEHandler`__
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:searchfox:`mozilla::widget::IMEHandler <widget/windows/WinIMEHandler.cpp>`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This class manages input method context of each window and makes ``IMMHandler``
 or ``TSFTextStore`` work with active IME and focused editor. This class has
 only static members, i.e., never created its instance.
 
-__ https://searchfox.org/firefox-main/source/widget/windows/WinIMEHandler.cpp
 
-`mozilla::widget::IMMHandler`__
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:searchfox:`mozilla::widget::IMMHandler <widget/windows/IMMHandler.cpp>`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This class is used when TSF mode is disabled by pref (``"intl.tsf.enabled"``
 since 108, formerly named ``"intl.tsf.enable"``) or active IME is for IMM
@@ -1004,10 +1012,9 @@ Typically, a process creates windows with default IM context. Therefore, this
 design is enough (ideally, an instance should be created per IM context,
 though). The singleton instance is created when it becomes necessary.
 
-__ https://searchfox.org/firefox-main/source/widget/windows/IMMHandler.cpp
 
-`mozilla::widget::TSFTextStore`__
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:searchfox:`mozilla::widget::TSFTextStore <widget/windows/TSFTextStore.cpp>`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This class handles IME events in TSF mode and when TIP (IME implemented with
 TSF) is active. This instances are created when an editable element gets focus
@@ -1062,30 +1069,29 @@ position's character rect (for a popup to indicate current input mode or next
 word suggestion list) or first character rect of the target clause of current
 composition (for a candidate list window of conversion).
 
-__ https://searchfox.org/firefox-main/source/widget/windows/TSFTextStore.cpp
 
 Mac
 ---
 
 Both IME and key events are handled in
-`TextInputHandler.mm <https://searchfox.org/firefox-main/source/widget/cocoa/TextInputHandler.mm>`__.
+:searchfox:`TextInputHandler.mm <widget/cocoa/TextInputHandler.mm>`.
 
 ``mozilla::widget::TextInputHandlerBase`` is the most base class.
 ``mozilla::widget::IMEInputHandler`` inherits ``TextInputHandlerBase`` and
 handles IME related events. ``mozilla::widget::TextInputHandler`` inherits
 ``TextInputHandlerBase`` and implements ``NSTextInput`` protocol of Cocoa. Its
 instance is created per
-`nsChildView <https://searchfox.org/firefox-main/source/widget/cocoa/nsChildView.mm>`__
+:searchfox:`nsChildView <widget/cocoa/nsChildView.mm>`
 instance.
 
 GTK
 ---
 
-`mozilla::widget::IMContextWrapper <https://searchfox.org/firefox-main/source/widget/gtk/IMContextWrapper.cpp>`__
+:searchfox:`mozilla::widget::IMContextWrapper <widget/gtk/IMContextWrapper.cpp>`
 handles IME. The instance is created per top level window.
 
 Android
 -------
 
-`org.mozilla.geckoview.GeckoEditable <https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoEditable.java>`__ handles native IME events and `mozilla::widget::GeckoEditableSupport <https://searchfox.org/firefox-main/source/widget/android/GeckoEditableSupport.cpp>`__
+:searchfox:`org.mozilla.geckoview.GeckoEditable <mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoEditable.java>` handles native IME events and :searchfox:`mozilla::widget::GeckoEditableSupport <widget/android/GeckoEditableSupport.cpp>`
 dispatches ``Widget*Event``.
diff --git a/extensions/permissions/docs/manager.rst b/extensions/permissions/docs/manager.rst
index 292466e0d40e..76929df6e0f2 100644
--- a/extensions/permissions/docs/manager.rst
+++ b/extensions/permissions/docs/manager.rst
@@ -13,16 +13,14 @@ a permission consists of the following:
    ``0`` (“Undefined”), ``1`` (“Allow”), ``2`` (“Deny”) or ``3`` (“Prompt the user”).
 
 For storing arbitrary preferences per origin instead of just permission values,
-the `content pref service
-<https://searchfox.org/firefox-main/source/dom/interfaces/base/nsIContentPrefService2.idl>`__
+the :searchfox:`content pref service <dom/interfaces/base/nsIContentPrefService2.idl>`
 offers a good alternative to the permission manager.
 
 The permission manager also supports :doc:`browser-scoped (per-tab) temporary
 permissions <browser-scoped>` that are not stored to disk and are automatically
 cleared when their tab is closed.
 
-The `site permission manager
-<https://searchfox.org/firefox-main/source/browser/modules/SitePermissions.sys.mjs>`__
+The :searchfox:`site permission manager <browser/modules/SitePermissions.sys.mjs>`
 builds on top of both regular and browser-scoped permissions, and makes user
 interfaces easier.
 
@@ -34,8 +32,7 @@ interface. This interface is available through the
 ``@mozilla.org/permissionmanager;1`` service, or through the quick
 ``Services.perms`` getter in JavaScript. Below is a list of the most common
 methods, and examples on how to use them with JavaScript. For a full list of
-signatures, see `nsIPermissionManager.idl
-<https://searchfox.org/firefox-main/source/netwerk/base/nsIPermissionManager.idl>`__.
+signatures, see :searchfox:`nsIPermissionManager.idl <netwerk/base/nsIPermissionManager.idl>`.
 
 ``testExactPermissionFromPrincipal``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/extensions/permissions/docs/remote.rst b/extensions/permissions/docs/remote.rst
index 870aa8ab4270..87490dcfbcac 100644
--- a/extensions/permissions/docs/remote.rst
+++ b/extensions/permissions/docs/remote.rst
@@ -14,8 +14,7 @@ HTTPS-First exceptions to be set through remote settings if a site is known to
 be broken with HTTPS-First. A bad example of remote permission would be using
 them to set permissions of the type ``uitour``. Permissions of that type grant
 sites access to a set of special APIs. These kinds of permissions should be set
-directly in source at `browser/app/permissions
-<https://searchfox.org/firefox-main/source/browser/app/permissions>`__.
+directly in source at :searchfox:`browser/app/permissions`.
 
 To limit the types of permissions that are allowed to be set through remote
 settings, the permission types that are allowed to be set through remote
diff --git a/gfx/docs/AsyncPanZoom.rst b/gfx/docs/AsyncPanZoom.rst
index 970eb01526ce..15cae5e1bb9c 100644
--- a/gfx/docs/AsyncPanZoom.rst
+++ b/gfx/docs/AsyncPanZoom.rst
@@ -785,7 +785,7 @@ Mochitest
 ~~~~~~~~~
 
 The APZ specific mochitests are useful when specific gestures or events need to be tested
-with specific content. The APZ mochitests are located in `gfx/layers/apz/test/mochitest`_.
+with specific content. The APZ mochitests are located in :searchfox:`gfx/layers/apz/test/mochitest`.
 To run all of the APZ mochitests, run something like the following:
 
 ::
@@ -793,11 +793,11 @@ To run all of the APZ mochitests, run something like the following:
     ./mach mochitest ./gfx/layers/apz/test/mochitest
 
 The APZ mochitests are often organized as subtests that run in a group. For example,
-the `test_group_hittest-2.html`_ contains >20 subtests like
-`helper_hittest_overscroll.html`_. When working on a specific subtest, it is often
+the :searchfox:`test_group_hittest-2.html <gfx/layers/apz/test/mochitest/test_group_hittest-2.html>` contains >20 subtests like
+:searchfox:`helper_hittest_overscroll.html <gfx/layers/apz/test/mochitest/helper_hittest_overscroll.html>`. When working on a specific subtest, it is often
 helpful to use the `apz.subtest` preference to filter the subtests run to just the
 tests you are working on. For example, the following would only run the
-`helper_hittest_overscroll.html`_ subtest of the `test_group_hittest-2.html`_ group.
+:searchfox:`helper_hittest_overscroll.html <gfx/layers/apz/test/mochitest/helper_hittest_overscroll.html>` subtest of the :searchfox:`test_group_hittest-2.html <gfx/layers/apz/test/mochitest/test_group_hittest-2.html>` group.
 
 ::
 
@@ -806,15 +806,12 @@ tests you are working on. For example, the following would only run the
 
 For more information on mochitest, see the `Mochitest Documentation`_.
 
-.. _gfx/layers/apz/test/mochitest: https://searchfox.org/firefox-main/source/gfx/layers/apz/test/mochitest
-.. _test_group_hittest-2.html: https://searchfox.org/firefox-main/source/gfx/layers/apz/test/mochitest/test_group_hittest-2.html
-.. _helper_hittest_overscroll.html: https://searchfox.org/firefox-main/source/gfx/layers/apz/test/mochitest/helper_hittest_overscroll.html
 .. _Mochitest Documentation: /testing/mochitest-plain/index.html
 
 GTest
 ~~~~~
 
-The APZ specific GTests can be found in `gfx/layers/apz/test/gtest/`_. To run
+The APZ specific GTests can be found in :searchfox:`gfx/layers/apz/test/gtest/`. To run
 these tests, run something like the following:
 
 ::
@@ -824,13 +821,12 @@ these tests, run something like the following:
 For more information, see the `GTest Documentation`_.
 
 .. _GTest Documentation: /gtest/index.html
-.. _gfx/layers/apz/test/gtest/: https://searchfox.org/firefox-main/source/gfx/layers/apz/test/gtest/
 
 Reftests
 ~~~~~~~~
 
-The APZ reftests can be found in `layout/reftests/async-scrolling/`_ and
-`gfx/layers/apz/test/reftest`_. To run the relevant reftests for APZ, run
+The APZ reftests can be found in :searchfox:`layout/reftests/async-scrolling/` and
+:searchfox:`gfx/layers/apz/test/reftest <gfx/layers/apz/test/reftest/>`. To run the relevant reftests for APZ, run
 a large portion of the APZ reftests, run something like the following:
 
 ::
@@ -843,8 +839,6 @@ There is no defined process for choosing which directory the APZ reftests
 should be placed in, but in general reftests should exist where other
 similar tests do.
 
-.. _layout/reftests/async-scrolling/: https://searchfox.org/firefox-main/source/layout/reftests/async-scrolling/
-.. _gfx/layers/apz/test/reftest: https://searchfox.org/firefox-main/source/gfx/layers/apz/test/reftest/
 .. _Reftest Documentation: /layout/Reftest.html
 
 Threading / Locking Overview
diff --git a/intl/docs/icu.rst b/intl/docs/icu.rst
index 59419b7e2fda..76d35cbb2f6f 100644
--- a/intl/docs/icu.rst
+++ b/intl/docs/icu.rst
@@ -137,7 +137,7 @@ Updating ICU will also update the language tag registry (which records language
 
 Often a local patch won’t apply, or new patches must be applied to successfully build. In this case you’ll have to manually edit ``update-icu.sh`` to abort after only *some* patches have been applied, make whatever changes are necessary by hand, generate a new/updated patch file by hand, then carefully reattempt updating. (The people who have updated ICU in the past, usually jwalden and anba, follow this awkward process and don’t have good ideas on how to improve it.)
 
-Any time ICU is updated, you’ll need to fully rebuild whichever of SpiderMonkey or Gecko you’re building. For SpiderMonkey, delete your object directory and reconfigure from scratch. For Gecko, change the message in the top-level `CLOBBER <https://searchfox.org/firefox-main/source/CLOBBER>`__ file.
+Any time ICU is updated, you’ll need to fully rebuild whichever of SpiderMonkey or Gecko you’re building. For SpiderMonkey, delete your object directory and reconfigure from scratch. For Gecko, change the message in the top-level :searchfox:`CLOBBER` file.
 
 Updating tzdata
 ~~~~~~~~~~~~~~~
diff --git a/ipc/docs/ipdl.rst b/ipc/docs/ipdl.rst
index dcb1903f15b6..603fc8d634fd 100644
--- a/ipc/docs/ipdl.rst
+++ b/ipc/docs/ipdl.rst
@@ -97,7 +97,7 @@ that represents the child.  The generated files are then automatically included
 in the C++ build process.  The generated classes contain public methods for
 sending the protocol messages, which client code will use as the entry-point to
 IPC communication.  The generated methods are built atop our IPC framework,
-defined in `/ipc <https://searchfox.org/firefox-main/source/ipc>`_, that
+defined in :searchfox:`/ipc <ipc>`, that
 standardizes the safe and secure use of sockets, pipes, shared memory, etc on
 all supported platforms.  See `Using The IPDL compiler`_ for more on
 integration with the build process.
@@ -107,10 +107,8 @@ to add handlers for the tasks generated to respond to each message.  It must
 also add routines (``ParamTraits``) that define serialization and
 deserialization for any types used in the payload of a message that aren't
 already known to the IPDL system.  Primitive types, and a bunch of Mozilla
-types, have predefined ``ParamTraits`` (`here
-<https://searchfox.org/firefox-main/source/ipc/glue/IPCMessageUtils.h>`__
-and `here
-<https://searchfox.org/firefox-main/source/ipc/glue/IPCMessageUtilsSpecializations.h>`__).
+types, have predefined ``ParamTraits`` (:searchfox:`here <ipc/glue/IPCMessageUtils.h>`
+and :searchfox:`here <ipc/glue/IPCMessageUtilsSpecializations.h>`).
 
 .. note::
     Among other things, client code that uses the generated code must include
@@ -588,7 +586,7 @@ can be any type that has a C++ ``ParamTraits`` specialization and is imported
 by a directive.  That said, there are some surprises in the list of messages:
 
 ================= =============================================================
-``int32_t``,...   The standard primitive types are included.  See `builtin.py`_
+``int32_t``,...   The standard primitive types are included.  See :searchfox:`builtin.py <ipc/ipdl/ipdl/builtin.py>`
                   for a list.  Pointer types are, unsurprisingly, forbidden.
 ``?``             When following a type T, the parameter is translated into
                   ``Maybe<T>`` in C++.
@@ -606,8 +604,6 @@ discussed in the next chapter; messages in particular are covered in `Actors
 and Messages in C++`_.  For suggestions on best practices when designing your
 IPDL actor approach, see `IPDL Best Practices`_.
 
-.. _builtin.py: https://searchfox.org/firefox-main/source/ipc/ipdl/ipdl/builtin.py
-
 IPDL Syntax Quick Reference
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -798,12 +794,9 @@ Most basic types and many essential Mozilla types are always available for use
 without inclusion.  An incomplete list includes: C++ primitives, strings
 (``std`` and ``mozilla``), vectors (``std`` and ``mozilla``), ``RefPtr<T>``
 (for serializable ``T``), ``UniquePtr<T>``, ``nsCOMPtr<T>``, ``nsTArray<T>``,
-``std::unordered_map<T>``, ``nsresult``, etc.  See `builtin.py
-<https://searchfox.org/firefox-main/source/ipc/ipdl/ipdl/builtin.py>`_,
-`ipc_message_utils.h
-<https://searchfox.org/firefox-main/source/ipc/chromium/src/chrome/common/ipc_message_utils.h>`_
-and `IPCMessageUtilsSpecializations.h
-<https://searchfox.org/firefox-main/source/ipc/glue/IPCMessageUtilsSpecializations.h>`_.
+``std::unordered_map<T>``, ``nsresult``, etc.  See :searchfox:`builtin.py <ipc/ipdl/ipdl/builtin.py>`,
+:searchfox:`ipc_message_utils.h <ipc/chromium/src/chrome/common/ipc_message_utils.h>`
+and :searchfox:`IPCMessageUtilsSpecializations.h <ipc/glue/IPCMessageUtilsSpecializations.h>`.
 
 ``ParamTraits`` typically bootstrap with the ``ParamTraits`` of more basic
 types, until they hit bedrock (e.g. one of the basic types above).  In the most
@@ -1110,8 +1103,7 @@ result of the [Tainted] annotation in the protocol file.  Recall that
 handler before their values can be used (as opposed to validation in
 ``ParamTraits``).  They therefore have access to any state that the message
 handler does.  Their APIs, along with a list of macros that are used to
-validate them, are detailed `here
-<https://searchfox.org/firefox-main/source/mfbt/Tainting.h>`__.
+validate them, are detailed :searchfox:`here <mfbt/Tainting.h>`.
 
 Send methods that are not for async messages with return values follow a
 simpler form; they return a ``bool`` indicating success or failure and return
@@ -1669,7 +1661,7 @@ while a sync messagee is waiting for a response.  The rules for when a nested
 message can be handled are somewhat complex but they try to safely allow a
 ``sync`` message ``M`` to handle and respond to some special (nested) messages
 that may be needed for the other endpoint to finish processing ``M``.  There is
-a `comment in MessageChannel`_ with info on how the decision to handle nested
+a :searchfox:`comment in MessageChannel <mozilla-central/rev/077501b34cca91763ae04f4633a42fddd919fdbd:ipc/glue/MessageChannel.cpp#54-118>` with info on how the decision to handle nested
 messages is made.  For sync nested messages, note that this implies a relay
 between the endpoints, which could dramatically affect their throughput.
 
@@ -1770,7 +1762,7 @@ The following tables explain what happens in all cases:
     \*                                 sync inside_cpow               IPDL compiler error: parent cannot use inside_cpow priority
     =============================      =========================      ========================================================
 
-We haven't seen rule #2 from the `comment in MessageChannel`_ in action but, as
+We haven't seen rule #2 from the :searchfox:`comment in MessageChannel <mozilla-central/rev/077501b34cca91763ae04f4633a42fddd919fdbd:ipc/glue/MessageChannel.cpp#54-118>` in action but, as
 the comment mentions, it is needed to break deadlocks in cases where both the
 parent and child are initiating message-threads simultaneously.  It
 accomplishes this by favoring the parent's sent messages over the child's when
@@ -1788,8 +1780,6 @@ objects.  Control flow, and hence state, can be very difficult to predict and
 are just as hard to maintain.  This is one of the key reasons why we have
 stressed that message priorities should be avoided whenever possible.
 
-.. _comment in MessageChannel: https://searchfox.org/mozilla-central/rev/077501b34cca91763ae04f4633a42fddd919fdbd/ipc/glue/MessageChannel.cpp#54-118
-
 .. _Message Logging:
 
 Message Logging
diff --git a/ipc/docs/processes.rst b/ipc/docs/processes.rst
index 071996128247..f1f1083093ac 100644
--- a/ipc/docs/processes.rst
+++ b/ipc/docs/processes.rst
@@ -163,8 +163,7 @@ we call **Demo**.
   for this actor to simply take the name of the process type.  The sample uses
   ``PDemo``, so it creates ``DemoParent`` and ``DemoChild`` actor subclasses
   as usual (see :ref:`IPDL: Inter-Thread and Inter-Process Message Passing`).
-* A subclass of `GeckoChildProcessHost
-  <https://searchfox.org/firefox-main/source/ipc/glue/GeckoChildProcessHost.h>`_
+* A subclass of :searchfox:`GeckoChildProcessHost <ipc/glue/GeckoChildProcessHost.h>`
   that exists in the main process (where new processes are created) and handles
   most of the machinery needed for new process creation.  It is common for these
   names to be the process type plus ``ProcessParent`` or ``ProcessHost``.  The
@@ -173,8 +172,7 @@ we call **Demo**.
   since it is large, complicated and mostly unimportant externally.  This
   complexity is also why it is a bad idea to add extra responsibilities to the
   ``Host`` object that inherits it.
-* A subclass of `ProcessChild
-  <https://searchfox.org/firefox-main/source/ipc/glue/ProcessChild.h>`_ that
+* A subclass of :searchfox:`ProcessChild <ipc/glue/ProcessChild.h>` that
   exists in the new process.  These names are usually generated by affixing
   ``ProcessChild`` or ``ProcessImpl`` to the type.  The sample will use
   ``DemoChild::Process``, another private class, for the same reasons it did
@@ -214,8 +212,7 @@ Process Bookkeeping
 ~~~~~~~~~~~~~~~~~~~
 .. _process-bookkeeping:
 
-To begin with, look at the `geckoprocesstypes generator
-<https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/geckoprocesstypes_generator/geckoprocesstypes/__init__.py>`_
+To begin with, look at the :searchfox:`geckoprocesstypes generator <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/geckoprocesstypes_generator/geckoprocesstypes/__init__.py>`
 which adds the bones for a new process (by defining enum values and so on).
 Some further manual intervention is still required, and you need to follow the
 following checklists depending on your needs.
@@ -223,34 +220,25 @@ following checklists depending on your needs.
 Basic requirements
 ^^^^^^^^^^^^^^^^^^
 
-* Add a new entry to the `enum WebIDLProcType
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/dom/chrome-webidl/ChromeUtils.webidl#610-638>`_
-* Update the `static_assert
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/xre/nsAppRunner.cpp#988-990>`_
+* Add a new entry to the :searchfox:`enum WebIDLProcType <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:dom/chrome-webidl/ChromeUtils.webidl#610-638>`
+* Update the :searchfox:`static_assert <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/xre/nsAppRunner.cpp#988-990>`
   call checking for boundary against ``GeckoProcessType_End``
 * Add your process to the correct ``MessageLoop::TYPE_x`` in the first
-  ``switch(XRE_GetProcessType())`` in `XRE_InitChildProcess
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/xre/nsEmbedFunctions.cpp#572-590>`__.
-  You can get more information about that topic in `this comment
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/ipc/chromium/src/base/message_loop.h#159-187>`_
+  ``switch(XRE_GetProcessType())`` in :searchfox:`XRE_InitChildProcess <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/xre/nsEmbedFunctions.cpp#572-590>`.
+  You can get more information about that topic in :searchfox:`this comment <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:ipc/chromium/src/base/message_loop.h#159-187>`
 * Instantiate your child within the second ``switch (XRE_GetProcessType())`` in
-  `XRE_InitChildProcess
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/xre/nsEmbedFunctions.cpp#615-671>`__
-* Add a new entry ``PROCESS_TYPE_x`` in `nsIXULRuntime interface
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/system/nsIXULRuntime.idl#183-196>`_
+  :searchfox:`XRE_InitChildProcess <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/xre/nsEmbedFunctions.cpp#615-671>`
+* Add a new entry ``PROCESS_TYPE_x`` in :searchfox:`nsIXULRuntime interface <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/system/nsIXULRuntime.idl#183-196>`
 
 Graphics
 ########
 
-If you need graphics-related interaction, hack into `gfxPlatform
-<https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/gfx/thebes/gfxPlatform.cpp>`__
+If you need graphics-related interaction, hack into :searchfox:`gfxPlatform <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:gfx/thebes/gfxPlatform.cpp>`
 
 - Add a call to your process manager init in ``gfxPlatform::Init()`` in
-  `gfxPlatform
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/gfx/thebes/gfxPlatform.cpp#808-810>`__
+  :searchfox:`gfxPlatform <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:gfx/thebes/gfxPlatform.cpp#808-810>`
 - Add a call to your process manager shutdown in ``gfxPlatform::Shutdown()`` in
-  `gfxPlatform
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/gfx/thebes/gfxPlatform.cpp#1255-1259>`__
+  :searchfox:`gfxPlatform <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:gfx/thebes/gfxPlatform.cpp#1255-1259>`
 
 Android
 #######
@@ -260,28 +248,22 @@ required or applicable to your new process type.
 
 - Add a new ``<service>`` entry against
   ``org.mozilla.gecko.process.GeckoChildProcessServices$XXX`` in the
-  `AndroidManifest
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/mobile/android/geckoview/src/main/AndroidManifest.xml#45-81>`_
-- Add matching class inheritance from `GeckoChildProcessServices
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/mobile/android/geckoview/src/main/java/org/mozilla/gecko/process/GeckoChildProcessServices.jinja#10-13>`_
-- Add new entry in `public enum GeckoProcessType
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/mobile/android/geckoview/src/main/java/org/mozilla/gecko/process/GeckoProcessType.java#11-23>`_
+  :searchfox:`AndroidManifest <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:mobile/android/geckoview/src/main/AndroidManifest.xml#45-81>`
+- Add matching class inheritance from :searchfox:`GeckoChildProcessServices <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:mobile/android/geckoview/src/main/java/org/mozilla/gecko/process/GeckoChildProcessServices.jinja#10-13>`
+- Add new entry in :searchfox:`public enum GeckoProcessType <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:mobile/android/geckoview/src/main/java/org/mozilla/gecko/process/GeckoProcessType.java#11-23>`
 
 Crash reporting
 ###############
 
-- Add ``InitCrashReporter`` message to the parent-side `InitCrashReporter
-  <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#30>`_
+- Add ``InitCrashReporter`` message to the parent-side :searchfox:`InitCrashReporter <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#30>`
 - Ensure your parent class inherits `public ipc::CrashReporterHelper<GeckoProcessType_Xxx>
   <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessParent.h#23>`_
-- Add new ``Xxx*Status`` `annotations
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/crashreporter/CrashAnnotations.yaml#968-971>`_
+- Add new ``Xxx*Status`` :searchfox:`annotations <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/crashreporter/CrashAnnotations.yaml#968-971>`
   entry for your new process type description. The link here points to
   `UtilityProcessStatus` so you can see the similar description you have to
   write, but you might want to respect ordering in that file and put your new
   code at the appropriate place.
-- Add entry in `PROCESS_CRASH_SUBMIT_ATTEMPT
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/telemetry/Histograms.json#13403-13422>`_ and
+- Add entry in :searchfox:`PROCESS_CRASH_SUBMIT_ATTEMPT <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/telemetry/Histograms.json#13403-13422>` and
   `submit_attempt` in `toolkit/components/crashes/metrics.yaml`.
 
 Memory reporting
@@ -291,23 +273,23 @@ Throughout the linked code, please consider those methods more as boilerplate co
 
 - Add definition of memory reporter to your new :ref:`top-level actor <Top Level Actors>`
 
-  + Type inclusion `MemoryReportTypes <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#6>`__
-  + To parent-side `AddMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#32>`__
-  + To child-side `RequestMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#44-48>`__
+  + Type inclusion :searchfox:`MemoryReportTypes <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#6>`
+  + To parent-side :searchfox:`AddMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#32>`
+  + To child-side :searchfox:`RequestMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#44-48>`
 
-- Add handling for your new process within `nsMemoryReporterManager::GetReportsExtended <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/xpcom/base/nsMemoryReporterManager.cpp#1813-1819>`_
+- Add handling for your new process within :searchfox:`nsMemoryReporterManager::GetReportsExtended <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:xpcom/base/nsMemoryReporterManager.cpp#1813-1819>`
 - Provide a process manager level abstraction
 
-  + Implement a new class deriving ``MemoryReportingProcess`` such as `UtilityMemoryReporter <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessManager.cpp#253-292>`_
-  + Write a `GetProcessMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessManager.cpp#294-300>`_
+  + Implement a new class deriving ``MemoryReportingProcess`` such as :searchfox:`UtilityMemoryReporter <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessManager.cpp#253-292>`
+  + Write a :searchfox:`GetProcessMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessManager.cpp#294-300>`
 
-- On the child side, provide an implementation for `RequestMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessChild.cpp#153-166>`__
+- On the child side, provide an implementation for :searchfox:`RequestMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessChild.cpp#153-166>`
 - On the parent side
 
-  + Provide an implementation for `RequestMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessParent.cpp#41-69>`__
-  + Provide an implementation for `AddMemoryReport <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessParent.cpp#71-77>`__
+  + Provide an implementation for :searchfox:`RequestMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessParent.cpp#41-69>`
+  + Provide an implementation for :searchfox:`AddMemoryReport <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessParent.cpp#71-77>`
 
-If you want to add a test that ensures proper behavior, you can have a look at the `utility process memory report test <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/test/browser/browser_utility_memoryReport.js>`_
+If you want to add a test that ensures proper behavior, you can have a look at the :searchfox:`utility process memory report test <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/test/browser/browser_utility_memoryReport.js>`
 
 Process reporting
 #################
@@ -316,27 +298,25 @@ Those elements will be used for exposing processes to users in some `about:`
 pages. You might want to ping `#fluent-reviewers` to ensure if you need your
 process there.
 
-- Add a `user-facing localizable name
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/locales/en-US/toolkit/global/processTypes.ftl#39-57>`_
+- Add a :searchfox:`user-facing localizable name <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/locales/en-US/toolkit/global/processTypes.ftl#39-57>`
   for your process, if needed
-- Hashmap from process type to user-facing string above in `const ProcessType
-  <https://searchfox.org/mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03/toolkit/modules/ProcessType.sys.mjs#10-16>`_
+- Hashmap from process type to user-facing string above in :searchfox:`const ProcessType <mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03:toolkit/modules/ProcessType.sys.mjs#10-16>`
 - For `about:processes` you will probably want to follow the following steps:
 
-  + Add handling for your new process type producing a unique `fluentName <https://searchfox.org/mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673/toolkit/components/aboutprocesses/content/aboutProcesses.js#472-539>`_, i.e., constructing a dynamic name is highly discouraged
-  + Add matching localization strings within `about:processes localization file <https://searchfox.org/mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673/toolkit/locales/en-US/toolkit/about/aboutProcesses.ftl#35-55>`_
-  + Add matching localization strings within `about:support localization file <https://searchfox.org/firefox-main/source/toolkit/locales/en-US/toolkit/global/processTypes.ftl#54-60>`_
+  + Add handling for your new process type producing a unique :searchfox:`fluentName <mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673:toolkit/components/aboutprocesses/content/aboutProcesses.js#472-539>`, i.e., constructing a dynamic name is highly discouraged
+  + Add matching localization strings within :searchfox:`about:processes localization file <mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673:toolkit/locales/en-US/toolkit/about/aboutProcesses.ftl#35-55>`
+  + Add matching localization strings within :searchfox:`about:support localization file <toolkit/locales/en-US/toolkit/global/processTypes.ftl#54-60>`
 
 Profiler
 ########
 
 - Add definition of ``PProfiler`` to your new IPDL
 
-  + Type inclusion `protocol PProfiler <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#9>`__
-  + Child-side `InitProfiler <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#42>`__
+  + Type inclusion :searchfox:`protocol PProfiler <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#9>`
+  + Child-side :searchfox:`InitProfiler <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#42>`
 
-- Make sure your initialization path contains a `SendInitProfiler <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessHost.cpp#222-223>`__. You will want to perform the call once a ``OnChannelConnected`` is issued, thus ensuring your new process is connected to IPC.
-- Provide an implementation for `InitProfiler <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessChild.cpp#147-151>`__
+- Make sure your initialization path contains a :searchfox:`SendInitProfiler <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessHost.cpp#222-223>`. You will want to perform the call once a ``OnChannelConnected`` is issued, thus ensuring your new process is connected to IPC.
+- Provide an implementation for :searchfox:`InitProfiler <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessChild.cpp#147-151>`
 
 - You will probably want to make sure your child process code register within the profiler a proper name, otherwise it will default to ``GeckoMain`` ; this can be done by issuing ``profiler_set_process_name(nsCString("XxX"))`` on the child init side.
 
@@ -355,34 +335,33 @@ StaticComponents code generation
   services, so you might have to ensure you have all your bases covered. Some of
   the components might not need to be updated as well.
 
-  + `libpref <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/modules/libpref/components.conf>`_
-  + `telemetry <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/telemetry/core/components.conf>`_
-  + `android <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/widget/android/components.conf>`_
-  + `gtk <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/widget/gtk/components.conf>`_
-  + `windows <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/widget/windows/components.conf>`_
-  + `base <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/base/components.conf>`_
-  + `components <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/components/components.conf>`_
-  + `ds <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/ds/components.conf>`_
-  + `threads <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/threads/components.conf>`_
-  + `cocoa kWidgetModule <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/widget/cocoa/nsWidgetFactory.mm#194-202>`_
-  + `build <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/build/components.conf>`_
-  + `XPCOMinit kXPCOMModule <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/build/XPCOMInit.cpp#172-180>`_
+  + :searchfox:`libpref <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:modules/libpref/components.conf>`
+  + :searchfox:`telemetry <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/telemetry/core/components.conf>`
+  + :searchfox:`android <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:widget/android/components.conf>`
+  + :searchfox:`gtk <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:widget/gtk/components.conf>`
+  + :searchfox:`windows <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:widget/windows/components.conf>`
+  + :searchfox:`base <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/base/components.conf>`
+  + :searchfox:`components <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/components/components.conf>`
+  + :searchfox:`ds <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/ds/components.conf>`
+  + :searchfox:`threads <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/threads/components.conf>`
+  + :searchfox:`cocoa kWidgetModule <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:widget/cocoa/nsWidgetFactory.mm#194-202>`
+  + :searchfox:`build <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/build/components.conf>`
+  + :searchfox:`XPCOMinit kXPCOMModule <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/build/XPCOMInit.cpp#172-180>`
 
-- Within `static components generator
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/components/gen_static_components.py>`_
+- Within :searchfox:`static components generator <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/components/gen_static_components.py>`
 
   + Add new definition in ``ProcessSelector`` for your new process
     ``ALLOW_IN_x_PROCESS = 0x..``
   + Add new process selector masks including your new process definition
   + Also add those into the ``PROCESSES`` structure
 
-- Within `module definition <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/components/Module.h>`_
+- Within :searchfox:`module definition <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/components/Module.h>`
 
   + Add new definition in ``enum ProcessSelector``
   + Add new process selector mask including the new definition
   + Update ``kMaxProcessSelector``
 
-- Within `nsComponentManager <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/xpcom/components/nsComponentManager.cpp>`_
+- Within :searchfox:`nsComponentManager <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:xpcom/components/nsComponentManager.cpp>`
 
   + Add new selector match in ``ProcessSelectorMatches`` for your new process
     (needed?)
@@ -394,60 +373,46 @@ Glean telemetry
 
 - Ensure your new IPDL includes on the child side
 
-  + `FlushFOGData
-    <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#55>`__
-  + `TestTriggerMetrics
-    <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/PUtilityProcess.ipdl#60>`__
+  + :searchfox:`FlushFOGData <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#55>`
+  + :searchfox:`TestTriggerMetrics <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/PUtilityProcess.ipdl#60>`
 
-- Provide a parent-side implementation for `FOGData
-  <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessParent.cpp#79-82>`__
-- Provide a child-side implementation for `FlushFOGData
-  <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessChild.cpp#179-183>`__
-- Child-side should flush its FOG data at IPC `ActorDestroy
-  <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessChild.cpp#199-201>`__
-- Child-side `test metrics
-  <https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/glue/UtilityProcessChild.cpp#185-191>`__
-- Within `FOGIPC
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/glean/ipc/FOGIPC.cpp>`__
+- Provide a parent-side implementation for :searchfox:`FOGData <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessParent.cpp#79-82>`
+- Provide a child-side implementation for :searchfox:`FlushFOGData <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessChild.cpp#179-183>`
+- Child-side should flush its FOG data at IPC :searchfox:`ActorDestroy <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessChild.cpp#199-201>`
+- Child-side :searchfox:`test metrics <mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc:ipc/glue/UtilityProcessChild.cpp#185-191>`
+- Within :searchfox:`FOGIPC <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/glean/ipc/FOGIPC.cpp>`
 
-  + Add handling of your new process type within ``FlushAllChildData()`` `here
-    <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/glean/ipc/FOGIPC.cpp#106-121>`__
-    and ``SendFOGData()`` `here
-    <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/glean/ipc/FOGIPC.cpp#165-182>`__
-  + Add support for sending test metrics in ``TestTriggerMetrics()`` `here
-    <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/glean/ipc/FOGIPC.cpp#208-232>`__
+  + Add handling of your new process type within ``FlushAllChildData()`` :searchfox:`here <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/glean/ipc/FOGIPC.cpp#106-121>`
+    and ``SendFOGData()`` :searchfox:`here <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/glean/ipc/FOGIPC.cpp#165-182>`
+  + Add support for sending test metrics in ``TestTriggerMetrics()`` :searchfox:`here <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/glean/ipc/FOGIPC.cpp#208-232>`
 
-- Handle process shutdown in ``register_process_shutdown()`` of `glean
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/toolkit/components/glean/api/src/ipc.rs>`__
+- Handle process shutdown in ``register_process_shutdown()`` of :searchfox:`glean <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:toolkit/components/glean/api/src/ipc.rs>`
 
 Third-Party Modules
 ###################
 
 - Ensure your new IPDL includes on the child side
 
-  + `GetUntrustedModulesData
-    <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/PUtilityProcess.ipdl#106>`_
-  + `UnblockUntrustedModulesThread
-    <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/PUtilityProcess.ipdl#113>`_
+  + :searchfox:`GetUntrustedModulesData <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/PUtilityProcess.ipdl#106>`
+  + :searchfox:`UnblockUntrustedModulesThread <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/PUtilityProcess.ipdl#113>`
 
 - Provide a parent side implementation for both
 
-- Add handling of your new process type in ``MultiGetUntrustedModulesData::GetUntrustedModuleLoadEvents()`` `here <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/toolkit/components/telemetry/other/UntrustedModules.cpp#145-151>`__
+- Add handling of your new process type in ``MultiGetUntrustedModulesData::GetUntrustedModuleLoadEvents()`` :searchfox:`here <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:toolkit/components/telemetry/other/UntrustedModules.cpp#145-151>`
 
-- `Update your IPDL <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/PUtilityProcess.ipdl#75>`_ and make sure your ``Init()`` can receive a boolean for
-  ``isReadyForBackgroundProcessing`` `like here <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/UtilityProcessChild.cpp#157-160>`_, then within the child's ``RecvInit()``
-  make sure a call to ``DllServices``'s ``StartUntrustedModulesProcessor()`` `is
-  performed <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/UtilityProcessChild.cpp#185-186>`_.
+- :searchfox:`Update your IPDL <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/PUtilityProcess.ipdl#75>` and make sure your ``Init()`` can receive a boolean for
+  ``isReadyForBackgroundProcessing`` :searchfox:`like here <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/UtilityProcessChild.cpp#157-160>`, then within the child's ``RecvInit()``
+  make sure a call to ``DllServices``'s ``StartUntrustedModulesProcessor()`` :searchfox:`is performed <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/UtilityProcessChild.cpp#185-186>`.
 
 - Ensure your new IPDL includes for the parent side
 
-  + `GetModulesTrust <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/PUtilityProcess.ipdl#60-61>`_
+  + :searchfox:`GetModulesTrust <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/PUtilityProcess.ipdl#60-61>`
 
-- Provide an implementation on the `parent side <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/ipc/glue/UtilityProcessParent.cpp#69-81>`_
+- Provide an implementation on the :searchfox:`parent side <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:ipc/glue/UtilityProcessParent.cpp#69-81>`
 
-- Expose your new process type as supported in ``UntrustedModulesProcessor::IsSupportedProcessType()`` `like others <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/toolkit/xre/dllservices/UntrustedModulesProcessor.cpp#76-91>`_
+- Expose your new process type as supported in ``UntrustedModulesProcessor::IsSupportedProcessType()`` :searchfox:`like others <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:toolkit/xre/dllservices/UntrustedModulesProcessor.cpp#76-91>`
 
-- Update ``UntrustedModulesProcessor::SendGetModulesTrust()`` to call `your new child process <https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/toolkit/xre/dllservices/UntrustedModulesProcessor.cpp#757-761>`_
+- Update ``UntrustedModulesProcessor::SendGetModulesTrust()`` to call :searchfox:`your new child process <mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a:toolkit/xre/dllservices/UntrustedModulesProcessor.cpp#757-761>`
 
 Sandboxing
 ##########
@@ -461,61 +426,43 @@ _____________
 
 Linux sandboxing mostly works by allowing / blocking system calls for child
 process and redirecting (brokering) some from the child to the parent. Rules
-are written in a specific DSL: `BPF
-<https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/chromium/sandbox/linux/bpf_dsl/bpf_dsl.h#21-72>`_.
+are written in a specific DSL: :searchfox:`BPF <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/chromium/sandbox/linux/bpf_dsl/bpf_dsl.h#21-72>`.
 
-- Add new ``SetXXXSandbox()`` function within `linux sandbox
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/Sandbox.cpp#719-748>`_
-- Within `sandbox filter
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/SandboxFilter.cpp>`_
+- Add new ``SetXXXSandbox()`` function within :searchfox:`linux sandbox <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/Sandbox.cpp#719-748>`
+- Within :searchfox:`sandbox filter <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/SandboxFilter.cpp>`
 
-  + Add new helper ``GetXXXSandboxPolicy()`` `like this one
-    <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/SandboxFilter.cpp#2036-2040>`_
+  + Add new helper ``GetXXXSandboxPolicy()`` :searchfox:`like this one <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/SandboxFilter.cpp#2036-2040>`
     called by ``SetXXXSandbox()``
-  + Derive new class `similar to this
-    <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/SandboxFilter.cpp#2000-2034>`_
+  + Derive new class :searchfox:`similar to this <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/SandboxFilter.cpp#2000-2034>`
     inheriting ``SandboxPolicyCommon`` or ``SandboxPolicyBase`` and defining
     the sandboxing policy
 
-- Add new ``SandboxBrokerPolicyFactory::GetXXXProcessPolicy()`` in `sandbox
-  broker
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#881-932>`_
-- Add new case handling in ``GetEffectiveSandboxLevel()`` in `sandbox launch
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/launch/SandboxLaunch.cpp#243-271>`_
-- Add new entry in ``enum class ProcType`` of `sandbox reporter header
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/reporter/SandboxReporterCommon.h#32-39>`_
-- Add new case handling in ``SubmitToTelemetry()`` in `sandbox reporter
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/reporter/SandboxReporter.cpp#131-152>`_
-- Add new case handling in ``SandboxReportWrapper::GetProcType()`` of `sandbox
-  reporter wrapper
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/linux/reporter/SandboxReporterWrappers.cpp#69-91>`_
+- Add new ``SandboxBrokerPolicyFactory::GetXXXProcessPolicy()`` in :searchfox:`sandbox broker <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#881-932>`
+- Add new case handling in ``GetEffectiveSandboxLevel()`` in :searchfox:`sandbox launch <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/launch/SandboxLaunch.cpp#243-271>`
+- Add new entry in ``enum class ProcType`` of :searchfox:`sandbox reporter header <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/reporter/SandboxReporterCommon.h#32-39>`
+- Add new case handling in ``SubmitToTelemetry()`` in :searchfox:`sandbox reporter <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/reporter/SandboxReporter.cpp#131-152>`
+- Add new case handling in ``SandboxReportWrapper::GetProcType()`` of :searchfox:`sandbox reporter wrapper <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/linux/reporter/SandboxReporterWrappers.cpp#69-91>`
 
 MacOS Sandbox
 _____________
 
 - Add new case handling in ``GeckoChildProcessHost::StartMacSandbox()`` of
-  `GeckoChildProcessHost <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/ipc/glue/GeckoChildProcessHost.cpp#1720-1743>`__
-- Add new entry in ``enum MacSandboxType`` defined in `macOS sandbox header
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/Sandbox.h#12-20>`__
-- Within `macOS sandbox core
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/Sandbox.mm>`__
+  :searchfox:`GeckoChildProcessHost <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:ipc/glue/GeckoChildProcessHost.cpp#1720-1743>`
+- Add new entry in ``enum MacSandboxType`` defined in :searchfox:`macOS sandbox header <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/Sandbox.h#12-20>`
+- Within :searchfox:`macOS sandbox core <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/Sandbox.mm>`
   handle the new ``MacSandboxType`` in
 
-   + ``MacSandboxInfo::AppendAsParams()`` in the `switch statement
-     <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/Sandbox.mm#164-188>`__
-   + ``StartMacSandbox()`` in the `series of if/else statements
-     <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/Sandbox.mm#286-436>`__.
+   + ``MacSandboxInfo::AppendAsParams()`` in the :searchfox:`switch statement <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/Sandbox.mm#164-188>`
+   + ``StartMacSandbox()`` in the :searchfox:`series of if/else statements <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/Sandbox.mm#286-436>`.
      This code sets template values for the sandbox string rendering, and is
      running on the side of the main process.
-   + ``StartMacSandboxIfEnabled()`` in this `switch statement
-     <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/Sandbox.mm#753-782>`__.
+   + ``StartMacSandboxIfEnabled()`` in this :searchfox:`switch statement <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/Sandbox.mm#753-782>`.
      You might also need a ``GetXXXSandboxParamsFromArgs()`` that performs CLI
      parsing on behalf of ``StartMacSandbox()``.
 
 - Create the new sandbox definition file
   ``security/sandbox/mac/SandboxPolicy<XXX>.h`` for your new process ``<XXX>``,
-  and make it exposed in the ``EXPORTS.mozilla`` section of `moz.build
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/mac/moz.build#7-13>`__.
+  and make it exposed in the ``EXPORTS.mozilla`` section of :searchfox:`moz.build <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/mac/moz.build#7-13>`.
   Those rules follows a specific Scheme-like language. You can learn more about
   it in `Apple Sandbox Guide
   <https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf>`__
@@ -526,31 +473,24 @@ _______________
 
 - Introduce a new ``SandboxBroker::SetSecurityLevelForXXXProcess()`` that
   defines the new sandbox in the sandbox broker basing yourself on this
-  `example <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1241-1344>`__
+  :searchfox:`example <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1241-1344>`
 
 - Add new case handling in ``WindowsProcessLauncher::DoSetup()`` calling
-  ``SandboxBroker::SetSecurityLevelForXXXProcess()`` in `GeckoChildProcessHost
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/ipc/glue/GeckoChildProcessHost.cpp#1391-1470>`__.
+  ``SandboxBroker::SetSecurityLevelForXXXProcess()`` in :searchfox:`GeckoChildProcessHost <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:ipc/glue/GeckoChildProcessHost.cpp#1391-1470>`.
   This will apply actual sandboxing rules to your process.
 
 Sandbox tests
 _____________
 
-- New process' first top level actor needs to `include PSandboxTesting
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/common/test/PSandboxTesting.ipdl>`_
-  and implement ``RecvInitSandboxTesting`` `like there
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/ipc/glue/UtilityProcessChild.cpp#165-174>`_.
-- Add your new process ``string_name`` in the ``processTypes`` list of `sandbox
-  tests <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/test/browser_sandbox_test.js#17>`_
-- Add a new case in ``SandboxTest::StartTests()`` in `test core
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/common/test/SandboxTest.cpp#100-232>`_
+- New process' first top level actor needs to :searchfox:`include PSandboxTesting <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/common/test/PSandboxTesting.ipdl>`
+  and implement ``RecvInitSandboxTesting`` :searchfox:`like there <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:ipc/glue/UtilityProcessChild.cpp#165-174>`.
+- Add your new process ``string_name`` in the ``processTypes`` list of :searchfox:`sandbox tests <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/test/browser_sandbox_test.js#17>`
+- Add a new case in ``SandboxTest::StartTests()`` in :searchfox:`test core <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/common/test/SandboxTest.cpp#100-232>`
   to handle your new process
 - Add a new if branch for your new process in ``SandboxTestingChild::Bind()``
-  in `testing child
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/common/test/SandboxTestingChild.cpp#68-96>`_
+  in :searchfox:`testing child <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/common/test/SandboxTestingChild.cpp#68-96>`
 - Add a new ``RunTestsXXX`` function for your new process (called by ``Bind()``
-  above) `similar to that implementation
-  <https://searchfox.org/mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854/security/sandbox/common/test/SandboxTestingChildTests.h#333-363>`_
+  above) :searchfox:`similar to that implementation <mozilla-central/rev/d4b9c457db637fde655592d9e2048939b7ab2854:security/sandbox/common/test/SandboxTestingChildTests.h#333-363>`
 
 Creating the New Process
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -721,10 +661,8 @@ is used to determine what process types have access to what XPCOM components.
 By default, a process has access to none.  The code adds enums for selecting
 a subset of process types, like
 ``ALLOW_IN_GPU_RDD_VR_SOCKET_UTILITY_AND_DEMO_PROCESS``, to the
-``ProcessSelector`` enum in `gen_static_components.py
-<https://searchfox.org/firefox-main/source/xpcom/components/gen_static_components.py>`_
-and `Module.h
-<https://searchfox.org/firefox-main/source/xpcom/components/Module.h>`_.
+``ProcessSelector`` enum in :searchfox:`gen_static_components.py <xpcom/components/gen_static_components.py>`
+and :searchfox:`Module.h <xpcom/components/Module.h>`.
 It then updates the selectors in various ``components.conf`` files and
 hardcoded spots like ``nsComponentManager.cpp`` to add the **Demo** processes
 to the list that can use them.  Some modules are required to bootstrap XPCOM
diff --git a/ipc/docs/utility_process.rst b/ipc/docs/utility_process.rst
index 6d4b93bbcf49..e6bbb9b8b14b 100644
--- a/ipc/docs/utility_process.rst
+++ b/ipc/docs/utility_process.rst
@@ -28,17 +28,17 @@ implementing the trivial example visible in `EmptyUtil
     performing the heavy lifting of starting your process, you can take
     inspiration from ``StartEmptyUtil()`` in the sample.
 
-  - Ideally, this starting method should rely on `StartUtility() <https://searchfox.org/mozilla-central/rev/f9f9b422f685244dcd3f6826b70d34a496ce5853/ipc/glue/UtilityProcessManager.cpp#238-318,347>`_
+  - Ideally, this starting method should rely on :searchfox:`StartUtility() <mozilla-central/rev/f9f9b422f685244dcd3f6826b70d34a496ce5853:ipc/glue/UtilityProcessManager.cpp#238-318,347>`
 
   - To use ``StartUtility()`` mentioned above, please ensure that you provide
     a ``nsresult BindToUtilityProcess(RefPtr<UtilityProcessParent>
     aUtilityParent)``. Usually, it should be in charge of creating a set of
-    endpoints and performing ``Bind()`` to setup the IPC. You can see some example for `UtilityMediaService <https://searchfox.org/mozilla-central/rev/0fe32133f12ed0f20d5fde8fe970157f04817982/ipc/glue/UtilityMediaServiceChild.cpp#60-92>`_
+    endpoints and performing ``Bind()`` to setup the IPC. You can see some example for :searchfox:`UtilityMediaService <mozilla-central/rev/0fe32133f12ed0f20d5fde8fe970157f04817982:ipc/glue/UtilityMediaServiceChild.cpp#60-92>`
 
   - For proper user-facing exposition in ``about:processes`` you will have to also provide an actor
     name via a method ``UtilityActorName GetActorName() { return UtilityActorName::EmptyUtil; }``
 
-    + Add member within `enum WebIDLUtilityActorName in <https://searchfox.org/mozilla-central/rev/f9f9b422f685244dcd3f6826b70d34a496ce5853/dom/chrome-webidl/ChromeUtils.webidl#852-866>`_
+    + Add member within :searchfox:`enum WebIDLUtilityActorName in <mozilla-central/rev/f9f9b422f685244dcd3f6826b70d34a496ce5853:dom/chrome-webidl/ChromeUtils.webidl#852-866>`
 
   - Handle reception of ``StartEmptyUtilService`` on the child side of
     ``UtilityProcess`` within ``RecvStartEmptyUtilService()``
@@ -48,22 +48,20 @@ implementing the trivial example visible in `EmptyUtil
     will probably include a reference to the ``EmptyUtilChild``.
 
   - The specific sandboxing requirements can be implemented by tracking
-    ``SandboxingKind``, and it starts within `UtilityProcessSandboxing header
-    <https://searchfox.org/firefox-main/source/ipc/glue/UtilityProcessSandboxing.h>`_
+    ``SandboxingKind``, and it starts within :searchfox:`UtilityProcessSandboxing header <ipc/glue/UtilityProcessSandboxing.h>`
 
   - Try and make sure you at least add some ``gtest`` coverage of your new
-    actor, for example like in `existing gtest
-    <https://searchfox.org/firefox-main/source/ipc/glue/test/gtest/TestUtilityProcess.cpp>`_
+    actor, for example like in :searchfox:`existing gtest <ipc/glue/test/gtest/TestUtilityProcess.cpp>`
 
   - Also ensure actual sandbox testing within
 
     + ``SandboxTest`` to start your new process,
-      `<https://searchfox.org/firefox-main/source/security/sandbox/common/test/SandboxTest.cpp>`_
+      :searchfox:`security/sandbox/common/test/SandboxTest.cpp`
 
     + ``SandboxTestingChildTests`` to define the test
-      `<https://searchfox.org/firefox-main/source/security/sandbox/common/test/SandboxTestingChildTests.h>`_
+      :searchfox:`security/sandbox/common/test/SandboxTestingChildTests.h`
 
     + ``SandboxTestingChild`` to run your test
-      `<https://searchfox.org/firefox-main/source/security/sandbox/common/test/SandboxTestingChild.cpp>`_
+      :searchfox:`security/sandbox/common/test/SandboxTestingChild.cpp`
 
   - Please also consider having a look at :ref:`Process Bookkeeping <process-bookkeeping>` for anything you may want to ensure is supported by your new process, like e.g. profiler, crash reporting, etc.
diff --git a/layout/docs/LayoutCodeReviewerChecklist.rst b/layout/docs/LayoutCodeReviewerChecklist.rst
index d83bfe432a88..94af12fb6163 100644
--- a/layout/docs/LayoutCodeReviewerChecklist.rst
+++ b/layout/docs/LayoutCodeReviewerChecklist.rst
@@ -15,8 +15,7 @@ Security issues
   - If you ever have a raw pointer to a dynamically allocated object, it's good
     to scrutinize whether the object might be destroyed before the last
     possible use of the raw pointer. For example: if you have a local variable
-    that points to an object that's owned by a `frame's property table
-    <https://searchfox.org/firefox-main/source/layout/base/FrameProperties.h>`__,
+    that points to an object that's owned by a :searchfox:`frame's property table <layout/base/FrameProperties.h>`,
     then consider whether the frame might remove/replace the property-table
     entry (or whether the frame itself might be destroyed) inside any of the
     function calls that happen while the local pointer is in scope.
diff --git a/layout/docs/index.rst b/layout/docs/index.rst
index 055807fa7a89..797602870b06 100644
--- a/layout/docs/index.rst
+++ b/layout/docs/index.rst
@@ -2,8 +2,7 @@ Style system (CSS) & Layout
 ===========================
 
 Here contains the overview and design documents for Firefox's layout engine and
-style system. They live in the mozilla-central repository under `layout/docs
-<https://searchfox.org/firefox-main/source/layout/docs>`__ directory.
+style system. They live in the mozilla-central repository under :searchfox:`layout/docs` directory.
 
 `Layout page <https://wiki.mozilla.org/Platform/Layout>`__ on mozilla wiki
 contains general information about layout and the layout team at Mozilla.
diff --git a/mobile/android/docs/geckoview/consumer/geckoview-quick-start.rst b/mobile/android/docs/geckoview/consumer/geckoview-quick-start.rst
index 3ee7e4ee05f2..50e8b25bd5c0 100644
--- a/mobile/android/docs/geckoview/consumer/geckoview-quick-start.rst
+++ b/mobile/android/docs/geckoview/consumer/geckoview-quick-start.rst
@@ -121,4 +121,4 @@ You're done!
 
 Your application should now load and display a webpage inside of GeckoView.
 
-To learn more about GeckoView's capabilities, review GeckoView's `JavaDoc <https://mozilla.github.io/geckoview/javadoc/mozilla-central/>`_ or the `reference application <https://searchfox.org/firefox-main/source/mobile/android/geckoview_example>`_.
+To learn more about GeckoView's capabilities, review GeckoView's `JavaDoc <https://mozilla.github.io/geckoview/javadoc/mozilla-central/>`_ or the :searchfox:`reference application <mobile/android/geckoview_example>`.
diff --git a/mobile/android/docs/geckoview/consumer/permissions.rst b/mobile/android/docs/geckoview/consumer/permissions.rst
index 044a8a512c64..76f87f036641 100644
--- a/mobile/android/docs/geckoview/consumer/permissions.rst
+++ b/mobile/android/docs/geckoview/consumer/permissions.rst
@@ -188,7 +188,7 @@ call, you will also receive the ``GeckoSession`` the request was sent
 from, the URI of the site that requested the permission, as a String,
 the list of video devices available, if requesting video, the list of
 audio devices available, if requesting audio, and a
-`MediaCallback <https://searchfox.org/firefox-main/source/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#686>`_
+:searchfox:`MediaCallback <mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#686>`
 to respond to the request.
 
 It is up to the app to present UI to the user asking for the
diff --git a/mobile/android/docs/geckoview/consumer/web-extensions.rst b/mobile/android/docs/geckoview/consumer/web-extensions.rst
index f5a9de261356..b13892866406 100644
--- a/mobile/android/docs/geckoview/consumer/web-extensions.rst
+++ b/mobile/android/docs/geckoview/consumer/web-extensions.rst
@@ -138,7 +138,7 @@ Let’s set up an activity that registers an extension located in the
 that will be used to communicate with Web Content.
 
 You can find the full example here:
-`MessagingExample <https://searchfox.org/firefox-main/source/mobile/android/examples/messaging_example>`_.
+:searchfox:`MessagingExample <mobile/android/examples/messaging_example>`.
 
 Activity.java
 ^^^^^^^^^^^^^
@@ -288,7 +288,7 @@ will allow you to receive a
 object that can be used to receive and send messages to the extension.
 
 The following example can be found
-`here <https://searchfox.org/firefox-main/source/mobile/android/examples/port_messaging_example>`_.
+:searchfox:`here <mobile/android/examples/port_messaging_example>`.
 
 For this example, the extension side will do the following:
 
diff --git a/mobile/android/docs/geckoview/contributor/for-gecko-engineers.rst b/mobile/android/docs/geckoview/contributor/for-gecko-engineers.rst
index 414e38506474..6225c48473a4 100644
--- a/mobile/android/docs/geckoview/contributor/for-gecko-engineers.rst
+++ b/mobile/android/docs/geckoview/contributor/for-gecko-engineers.rst
@@ -24,7 +24,7 @@ served by our general bootstrapping guide. If you are looking to
 contribute to front-end development of one of Mozilla’s Android
 browsers, you’re likely better off starting with their codebase and
 returning here only if actual GeckoView changes are needed. See, for
-example, `Fenix on Mozilla Central <https://searchfox.org/firefox-main/source/mobile/android/fenix>`_.
+example, :searchfox:`Fenix on Mozilla Central <mobile/android/fenix>`.
 
 What to do if this guide contains bugs or leads you astray: The quickest
 way to get a response is to ask generally on #gv on Mozilla Slack;
diff --git a/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst b/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst
index 55ad5746f992..d6ffd7a34104 100644
--- a/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst
+++ b/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst
@@ -136,8 +136,8 @@ the associated ``SurfaceView`` or ``TextureView``. This triggers a few actions
 on the Gecko side:
 
 - The GL Surface is released, and Gecko is notified in
-  `SyncPauseCompositor <https://searchfox.org/mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9/widget/android/nsWindow.cpp#1114>`_.
-- The ``<browser>`` associated to the ``GeckoSession`` is `set to inactive <https://searchfox.org/mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#553>`_,
+  :searchfox:`SyncPauseCompositor <mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9:widget/android/nsWindow.cpp#1114>`.
+- The ``<browser>`` associated to the ``GeckoSession`` is :searchfox:`set to inactive <mozilla-central/rev/ead7da2d9c5400bc7034ff3f06a030531bd7e5b9:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#553>`,
   which essentially freezes the JavaScript engine.
 
 Apps that do not use ``GeckoView``, because e.g. they cannot use
@@ -253,8 +253,7 @@ default, read Android's CA store to determine root certificates.
 However, GeckoView provides a way to import all third-party CA roots added to
 the Android CA store by setting the `enterpriseRootsEnabled
 <https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/GeckoRuntimeSettings.Builder.html#enterpriseRootsEnabled(boolean)>`_
-runtime setting to ``true``, this feature is implemented in `EnterpriseRoots
-<https://searchfox.org/mozilla-central/rev/26a6a38fb515dbab0bb459c40ec4b877477eefef/mobile/android/geckoview/src/main/java/org/mozilla/gecko/EnterpriseRoots.java>`_
+runtime setting to ``true``, this feature is implemented in :searchfox:`EnterpriseRoots <mozilla-central/rev/26a6a38fb515dbab0bb459c40ec4b877477eefef:mobile/android/geckoview/src/main/java/org/mozilla/gecko/EnterpriseRoots.java>`
 
 There is not currently any API for an app to manually specify additional CA
 roots, although this might change with `Bug 1522162
@@ -430,8 +429,7 @@ The underlying assumption is that a session that is not visible doesn't have a
 surface associated to it and it's not being used by the user so it shouldn't
 receive high priority status.
 
-The way this is implemented is `by setting
-<https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#114,123>`_
+The way this is implemented is :searchfox:`by setting <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#114,123>`
 the ``active`` property on the ``browser`` object to ``false``, which causes
 Gecko to de-prioritize the process, assuming that no other windows in the same
 process have ``active=true``. See also `GeckoDisplay`_.
@@ -450,8 +448,7 @@ priority, `setPriorityHint
 <https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/GeckoSession.html#setPriorityHint(int)>`_.
 The priority hint is taken into consideration when calculating the
 priority of a process.  Any process that contains either an active session or a
-session with the priority hint `is boosted
-<https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/dom/ipc/BrowserParent.cpp#3593>`_
+session with the priority hint :searchfox:`is boosted <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:dom/ipc/BrowserParent.cpp#3593>`
 to the highest priority.
 
 Shutdown
@@ -468,8 +465,7 @@ Principals
 ----------
 
 In Gecko, a *website* loaded in a session is represented by an abstraction
-called `principal
-<https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/caps/nsIPrincipal.idl>`__.
+called :searchfox:`principal <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:caps/nsIPrincipal.idl>`.
 Principals contain information that is used to determine what permissions have
 been granted to the website instance, what APIs are available to it, which
 container the page is loaded in, is the page in private browsing or not, etc.
@@ -690,24 +686,18 @@ Implementation
 ~~~~~~~~~~~~~~
 
 The main entry point from Gecko is ``nsIContentPermissionPrompt.prompt``, which
-is handled in the `Permission module
-<https://searchfox.org/mozilla-central/rev/256f84391cf5d4e3a4d66afbbcd744a5bec48956/mobile/android/components/geckoview/GeckoViewPermission.jsm#21>`_
+is handled in the :searchfox:`Permission module <mozilla-central/rev/256f84391cf5d4e3a4d66afbbcd744a5bec48956:mobile/android/components/geckoview/GeckoViewPermission.jsm#21>`
 in the same process where the request is originated.
 
-The permission module calls the child actor `GeckoViewPermission
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/actors/GeckoViewPermissionChild.jsm#47>`_
-which issues a `GeckoView:ContentPermission
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/actors/GeckoViewPermissionChild.jsm#75>`_
+The permission module calls the child actor :searchfox:`GeckoViewPermission <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/actors/GeckoViewPermissionChild.jsm#47>`
+which issues a :searchfox:`GeckoView:ContentPermission <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/actors/GeckoViewPermissionChild.jsm#75>`
 request to the Java front-end as needed.
 
 Media permissions are requested using a global observer, and therefore are
-handled in a `Process actor
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/actors/GeckoViewPermissionProcessChild.jsm#41>`_,
+handled in a :searchfox:`Process actor <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/actors/GeckoViewPermissionProcessChild.jsm#41>`,
 media permissions requests have enough information to redirect the request to
 the corresponding window child actor, with the exception of requests that are
-not associated with a window, which are redirected to the `current active
-window
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/actors/GeckoViewPermissionProcessParent.jsm#28-35>`_.
+not associated with a window, which are redirected to the :searchfox:`current active window <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/actors/GeckoViewPermissionProcessParent.jsm#28-35>`.
 
 Setting permissions
 ~~~~~~~~~~~~~~~~~~~
@@ -725,8 +715,7 @@ permission is given to the wrong website.
 Internally, some permissions are only present when a certain override is set,
 e.g. Tracking Protection override permissions are only present when the page
 has been given a TP override. Because the only way to set the value of a
-permission is to get hold of the ``ContentPermission`` object, `we manually insert
-<https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/mobile/android/modules/geckoview/GeckoViewNavigation.jsm#605-625>`_
+permission is to get hold of the ``ContentPermission`` object, :searchfox:`we manually insert <mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0:mobile/android/modules/geckoview/GeckoViewNavigation.jsm#605-625>`
 a `trackingprotection` permission on every page load.
 
 Autofill Support
@@ -737,20 +726,16 @@ GeckoView supports third-party autofill providers through Android's `autofill fr
 Document tree
 ~~~~~~~~~~~~~
 
-The autofill Java front-end is located in the `Autofill class
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#37>`_.
+The autofill Java front-end is located in the :searchfox:`Autofill class <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#37>`.
 GeckoView maintains a virtual tree structure of the current document for each
 ``GeckoSession``.
 
-The virtual tree structure is composed of `Node
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#593>`_
+The virtual tree structure is composed of :searchfox:`Node <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#593>`
 objects which are immutable. Data associated to a node, including mutable data
-like the current value, is stored in a separate `NodeData
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#171>`_
+like the current value, is stored in a separate :searchfox:`NodeData <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#171>`
 class. Only HTML nodes that are relevant to autofilling are referenced in the
 virtual structure and each node is associated to a root node, e.g. the root
-``<form>`` element. All root nodes are children of the autofill `mRoot
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#210>`_
+``<form>`` element. All root nodes are children of the autofill :searchfox:`mRoot <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/Autofill.java#210>`
 node, hence making the overall structure a tree rather than a collection of
 trees. Note that the root node is the only node in the virtual structure that
 does not correspond to an actual element on the page.
@@ -761,8 +746,7 @@ Javascript. The autofill framework itself requires integer IDs for nodes, so we
 store a mapping between UUIDs and integer IDs in the associated ``NodeData``
 object. The integer IDs are used only externally, while internally only the
 UUIDs are used. The reason why we use a separate ID structure from the autofill
-framework is that this allows us to `generate UUIDs
-<https://searchfox.org/mozilla-central/rev/7e34cb7a0094a2f325a0c9db720cec0a2f2aca4f/mobile/android/actors/GeckoViewAutoFillChild.jsm#217-220>`_
+framework is that this allows us to :searchfox:`generate UUIDs <mozilla-central/rev/7e34cb7a0094a2f325a0c9db720cec0a2f2aca4f:mobile/android/actors/GeckoViewAutoFillChild.jsm#217-220>`
 directly in the isolated content processes avoiding an IPC roundtrip to the
 main process.
 
@@ -773,8 +757,7 @@ Detecting autofillable nodes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 GeckoView scans every web page for password ``<input>`` elements whenever the
-``pageshow`` event `fires
-<https://searchfox.org/mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a/mobile/android/actors/GeckoViewAutoFillChild.jsm#74-78>`_.
+``pageshow`` event :searchfox:`fires <mozilla-central/rev/9dc5ffe42635b602d4ddfc9a4b8ea0befc94975a:mobile/android/actors/GeckoViewAutoFillChild.jsm#74-78>`.
 
 It also uses ``DOMFormHasPassword`` and ``DOMInputPasswordAdded`` to detect
 whenever a password element is added to the DOM after the ``pageshow`` event.
diff --git a/mobile/android/docs/geckoview/contributor/geckoview-quick-start.rst b/mobile/android/docs/geckoview/contributor/geckoview-quick-start.rst
index a948a2059431..5c1583344204 100644
--- a/mobile/android/docs/geckoview/contributor/geckoview-quick-start.rst
+++ b/mobile/android/docs/geckoview/contributor/geckoview-quick-start.rst
@@ -228,7 +228,7 @@ Finally, follow the next command to get the API hash for the CHANGELOG:
 
     ./mach lint --linter android-api-lint
 
-In the `CHANGELOG` `file <https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md>`_.
+In the `CHANGELOG` :searchfox:`file <mobile/android/geckoview/src/main/java/org/mozilla/geckoview/doc-files/CHANGELOG.md>`.
 at the bottom, swap `[api-version]` with the new hash provided by the linter and add an entry for what changed.
 
 The feature and methods should also be documented in the changelog similar to the example below.
diff --git a/mobile/android/docs/geckoview/contributor/junit.rst b/mobile/android/docs/geckoview/contributor/junit.rst
index 1294be1107c0..0277240b2967 100644
--- a/mobile/android/docs/geckoview/contributor/junit.rst
+++ b/mobile/android/docs/geckoview/contributor/junit.rst
@@ -2,10 +2,8 @@
 Junit Test Framework
 ====================
 
-GeckoView has `a lot
-<https://searchfox.org/mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java>`_
-of `custom
-<https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support>`_
+GeckoView has :searchfox:`a lot <mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java>`
+of :searchfox:`custom <mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support>`
 code that is used to run junit tests. This document is an overview of what this
 code does and how it works.
 
@@ -57,11 +55,9 @@ is fully installed:
 
   public GeckoResult<WebExtension> install(...)
 
-To simplify memory safety, ``GeckoResult`` will always `execute callbacks
-<https://searchfox.org/mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoResult.java#740-744>`_
+To simplify memory safety, ``GeckoResult`` will always :searchfox:`execute callbacks <mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoResult.java#740-744>`
 in the same thread where it was created, turning asynchronous code into
-single-threaded javascript-style code. This is currently `implemented
-<https://searchfox.org/mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoResult.java#285>`_
+single-threaded javascript-style code. This is currently :searchfox:`implemented <mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3:mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoResult.java#285>`
 using the Android Looper for the thread, which restricts ``GeckoResult`` to
 threads that have a looper, like the Android UI thread.
 
@@ -80,8 +76,7 @@ and most of the test framework is built around making sure that these
 interactions are easy to write and verify.
 
 Tests in GeckoView can be run using the ``mach`` interface, which is used by
-most Gecko tests. E.g. to run the `loadUnknownHost
-<https://searchfox.org/mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/NavigationDelegateTest.kt#186-196>`_
+most Gecko tests. E.g. to run the :searchfox:`loadUnknownHost <mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/NavigationDelegateTest.kt#186-196>`
 test in ``NavigationDelegateTest`` you would type on your terminal:
 
 .. code:: shell
@@ -119,8 +114,7 @@ through Android Studio, the prefs will be inherited from the default GeckoView
 prefs (i.e. the same prefs that would be enabled in a consumer's build of
 GeckoView) and the mochitest web server will not be available.
 
-Tests account for this using the `isAutomation
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/Environment.java#36-38>`_
+Tests account for this using the :searchfox:`isAutomation <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/Environment.java#36-38>`
 check, which essentially checks whether the test is running under ``mach`` or
 via Android Studio.
 
@@ -130,10 +124,8 @@ thread. Without this, every test would most likely include a lot of blocks that
 run code in the UI thread, adding significant boilerplate.
 
 Running tests on the UI thread is achieved by registering a custom ``TestRule``
-called `GeckoSessionTestRule
-<https://searchfox.org/mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/NavigationDelegateTest.kt#186-196>`_,
-which, among other things, `overrides the evaluate
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1307,1312>`_
+called :searchfox:`GeckoSessionTestRule <mozilla-central/rev/36904ac58d2528fc59f640db57cc9429103368d3:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/NavigationDelegateTest.kt#186-196>`,
+which, among other things, :searchfox:`overrides the evaluate <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1307,1312>`
 method and wraps everything into a ``instrumentation.runOnMainSync`` call.
 
 Verifying delegates
@@ -181,23 +173,16 @@ Tracking delegate calls
 One thing you might have noticed in the above section is that
 ``forCallbacksDuringWait`` moves "backward" in time by replaying the delegates
 called that happened while the wait was being executed.
-``GeckoSessionTestRule`` achieves this by `injecting a proxy object
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1137>`_
-into every delegate, and `proxying every call
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1091-1092>`_
+``GeckoSessionTestRule`` achieves this by :searchfox:`injecting a proxy object <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1137>`
+into every delegate, and :searchfox:`proxying every call <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1091-1092>`
 to the current delegate according to the ``delegate`` test calls.
 
-The proxy delegate `is built
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1105-1106>`_
-using the Java reflection's ``Proxy.newProxyInstance`` method and receives `a
-callback
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1030-1031>`_
+The proxy delegate :searchfox:`is built <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1105-1106>`
+using the Java reflection's ``Proxy.newProxyInstance`` method and receives :searchfox:`a callback <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1030-1031>`
 every time a method on the delegate is being executed.
 
-``GeckoSessionTestRule`` maintains a list of `"default" delegates
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#743-752>`_
-used in GeckoView, and will `use reflection
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#585>`_
+``GeckoSessionTestRule`` maintains a list of :searchfox:`"default" delegates <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#743-752>`
+used in GeckoView, and will :searchfox:`use reflection <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#585>`
 to match the object passed into the ``delegate*`` calls to the proxy delegates.
 
 For example, when calling
@@ -222,8 +207,7 @@ continue or not. When replaying delegates, however, we don't know what the
 value of ``onLoadRequest`` will be (or if the test is going to install a
 delegate for it, either!).
 
-What ``GeckoSessionTestRule`` does, instead, is to `return the default value
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1092>`_
+What ``GeckoSessionTestRule`` does, instead, is to :searchfox:`return the default value <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1092>`
 for the delegate method, and ignore the replayed delegate method return value.
 This can be a little confusing for test writers, for example this code `will
 not` stop the page from loading:
@@ -247,21 +231,16 @@ Tracking Waits
 --------------
 
 To track when a ``wait`` occurs and to know when to replay delegate calls,
-``GeckoSessionTestRule`` `stores
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1075>`_
+``GeckoSessionTestRule`` :searchfox:`stores <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1075>`
 the list of delegate calls in a ``List<CallRecord>`` object, where
 ``CallRecord`` is a class that has enough information to replay a delegate
-call. The test rule will track the `start and end index
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1619>`_
-of the last wait's delegate calls and `replay it
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1697-1724>`_
+call. The test rule will track the :searchfox:`start and end index <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1619>`
+of the last wait's delegate calls and :searchfox:`replay it <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1697-1724>`
 when ``forCallbacksDuringWait`` is called.
 
-To wait until a delegate call happens, the test rule will first `examine
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1585>`_
+To wait until a delegate call happens, the test rule will first :searchfox:`examine <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1585>`
 the already executed delegate calls using the call record list described above.
-If none of the calls match, then it will `wait for new calls
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1589>`_
+If none of the calls match, then it will :searchfox:`wait for new calls <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1589>`
 to happen, using ``UiThreadUtils.waitForCondition``.
 
 ``waitForCondition`` is also used to implement other type of ``wait*`` methods
@@ -269,11 +248,9 @@ like ``waitForResult``, which waits until a ``GeckoResult`` is executed.
 
 ``waitForCondition`` runs on the UI thread, and it synchronously waits for an
 event to occur. The events it waits for normally execute on the UI thread as
-well, so it `injects itself
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/UiThreadUtils.java#145,153>`_
+well, so it :searchfox:`injects itself <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/UiThreadUtils.java#145,153>`
 in the Android event loop, checking for the condition after every event has
-executed. If no more events remain in the queue, `it posts a delayed 100ms
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/UiThreadUtils.java#136-141>`_
+executed. If no more events remain in the queue, :searchfox:`it posts a delayed 100ms <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/util/UiThreadUtils.java#136-141>`
 task to avoid clogging the event loop.
 
 Executing Javascript
@@ -296,8 +273,7 @@ and install it. This was done intentionally to avoid having to rewrite a lot of
 the Web-Content-related APIs that the WebExtension API offers.
 
 GeckoView extends the WebExtension API to allow embedders to communicate to the
-extension by `overloading
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/modules/geckoview/GeckoViewWebExtension.jsm#221>`_
+extension by :searchfox:`overloading <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/modules/geckoview/GeckoViewWebExtension.jsm#221>`
 the native messaging API (which is not normally implemented on mobile).
 Embedders can register themselves as a `native app
 <https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/WebExtension.MessageDelegate.html>`_
@@ -315,28 +291,20 @@ WebView offers, but nothing has been developed so far.
 The test runner extension
 -------------------------
 
-To run arbitrary javascript in GeckoView, the test runner installs a `support
-extension
-<https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support>`_.
+To run arbitrary javascript in GeckoView, the test runner installs a :searchfox:`support extension <mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support>`.
 
-The test framework then `establishes
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1827>`_
+The test framework then :searchfox:`establishes <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1827>`
 a port for the background script, used to run code in the main process, and a
 port for every window, to be able to run javascript on test web pages.
 
-When ``evaluateJS`` is called, the test framework will send `a message
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1912>`_
-to the extension which then `calls eval
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support/test-support.js#21>`_
-on it and returns the `JSON`-stringified version of the result `back
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1952-1956>`_
+When ``evaluateJS`` is called, the test framework will send :searchfox:`a message <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1912>`
+to the extension which then :searchfox:`calls eval <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support/test-support.js#21>`
+on it and returns the `JSON`-stringified version of the result :searchfox:`back <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1952-1956>`
 to the test framework.
 
-The test framework also supports promises with `evaluatePromiseJS
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1888>`_.
+The test framework also supports promises with :searchfox:`evaluatePromiseJS <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1888>`.
 It works similarly to ``evaluateJS`` but instead of returning the stringified
-value, it `sets
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1879>`_
+value, it :searchfox:`sets <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1879>`
 the return value of the ``eval`` call into the ``this`` object, keyed by a
 randomly-generated UUID.
 
@@ -345,9 +313,7 @@ randomly-generated UUID.
   this[uuid] = eval(...)
 
 ``evaluatePromiseJS`` then returns an ``ExtensionPromise`` Java object which
-has a ``getValue`` method on it, which will essentially execute `await
-this[uuid]
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1883-1885>`_
+has a ``getValue`` method on it, which will essentially execute :searchfox:`await this[uuid] <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#1883-1885>`
 to get the value from the promise when needed.
 
 Beyond executing javascript
@@ -359,13 +325,11 @@ Gecko front-end, which is written in JavaScript, and don't have limits on what
 they can do. Experiment extensions are essentially what old add-ons used to be
 in Firefox, very powerful and very dangerous.
 
-The test runner uses experiments to offer `privileged APIs
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support/test-api.js>`_
+The test runner uses experiments to offer :searchfox:`privileged APIs <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/assets/web_extensions/test-support/test-api.js>`
 to tests like ``setPref`` or ``getLinkColor`` (which is not normally available
 to websites for privacy concerns).
 
-Each privileged API is exposed as an `ordinary Java API
-<https://searchfox.org/mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b/mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#2101>`_
+Each privileged API is exposed as an :searchfox:`ordinary Java API <mozilla-central/rev/95d8478112eecdd0ee249a941788e03f47df240b:mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/rule/GeckoSessionTestRule.java#2101>`
 and the test framework doesn't offer a way to run arbitrary chrome code to
 discourage developers from relying too much on implementation-dependent
 privileged code.
diff --git a/mobile/android/docs/geckoview/design/save-to-pdf.rst b/mobile/android/docs/geckoview/design/save-to-pdf.rst
index 5fe309ef30a5..96b299c75338 100644
--- a/mobile/android/docs/geckoview/design/save-to-pdf.rst
+++ b/mobile/android/docs/geckoview/design/save-to-pdf.rst
@@ -92,7 +92,7 @@ GeckoViewPdf.sys.mjs
   }
 
   async saveToPDF() {
-   // Reference: https://searchfox.org/firefox-main/source/remote/cdp/domains/parent/Page.sys.mjs#519
+   // Reference: :searchfox:`remote/cdp/domains/parent/Page.sys.mjs#519`
   }
 
 
diff --git a/mobile/android/docs/geckoview/index.rst b/mobile/android/docs/geckoview/index.rst
index 2f2f8cfe65a7..788db4d713ae 100644
--- a/mobile/android/docs/geckoview/index.rst
+++ b/mobile/android/docs/geckoview/index.rst
@@ -29,6 +29,6 @@ More information
 
 * Talk to us on `Matrix <https://chat.mozilla.org/#/room/#geckoview:mozilla.org>`_
 * `GeckoView Wiki <https://wiki.mozilla.org/Mobile/GeckoView>`_
-* `GeckoView Source Code <https://searchfox.org/firefox-main/source/mobile/android/geckoview>`_
+* :searchfox:`GeckoView Source Code <mobile/android/geckoview>`
 * `Raise a bug on GeckoView code <https://bugzilla.mozilla.org/enter_bug.cgi?product=GeckoView>`_
 * `Raise a documentation bug <https://github.com/mozilla/geckoview/issues>`_
diff --git a/mobile/android/docs/index.rst b/mobile/android/docs/index.rst
index 64ff54599e29..1653e2e2d4bf 100644
--- a/mobile/android/docs/index.rst
+++ b/mobile/android/docs/index.rst
@@ -205,7 +205,7 @@ Then the AVD can be created with:
 
 The name passed in argument can be whatever you want and the package is one of
 the installed list.  It is then required to modify entries within
-`android_device.py <https://searchfox.org/mozilla-central/rev/d56687458d4e6e8882c4b740e78413a0f0a69d59/testing/mozbase/mozrunner/mozrunner/devices/android_device.py#101-175>`_ to be able to make use of ``mach android-emulator``,
+:searchfox:`android_device.py <mozilla-central/rev/d56687458d4e6e8882c4b740e78413a0f0a69d59:testing/mozbase/mozrunner/mozrunner/devices/android_device.py#101-175>` to be able to make use of ``mach android-emulator``,
 changing the definition to match the name of the AVD created above. Example below:
 
 .. code:: diff
diff --git a/netwerk/docs/cache2/doc.rst b/netwerk/docs/cache2/doc.rst
index fcb0eaf71db5..3d98916123bf 100644
--- a/netwerk/docs/cache2/doc.rst
+++ b/netwerk/docs/cache2/doc.rst
@@ -3,8 +3,7 @@ HTTP Cache
 
 This document describes the **HTTP cache implementation**.
 
-The code resides in `/netwerk/cache2 (searchfox)
-<https://searchfox.org/firefox-main/source/netwerk/cache2>`_
+The code resides in :searchfox:`/netwerk/cache2 (searchfox) <netwerk/cache2>`
 
 API
 ---
@@ -27,7 +26,7 @@ nsICacheStorageService
 -  The HTTP cache entry-point. Accessible as a service only, fully
    thread-safe, scriptable.
 
--  `nsICacheStorageService.idl (searchfox) <https://searchfox.org/firefox-main/source/netwerk/cache2/nsICacheStorageService.idl>`_
+-  :searchfox:`nsICacheStorageService.idl (searchfox) <netwerk/cache2/nsICacheStorageService.idl>`
 
 -   \ ``"@mozilla.org/netwerk/cache-storage-service;1"``
 
@@ -73,7 +72,7 @@ nsILoadContextInfo
 
 -  Mandatory argument to ``*Storage`` methods of :ref:`nsICacheStorageService <nsICacheStorageService>`.
 
--  `nsILoadContextInfo.idl (searchfox) <https://searchfox.org/firefox-main/source/netwerk/base/nsILoadContextInfo.idl>`_
+-  :searchfox:`nsILoadContextInfo.idl (searchfox) <netwerk/base/nsILoadContextInfo.idl>`
 
 
 -  It is a helper interface wrapping following four arguments into a single one:
@@ -105,7 +104,7 @@ nsILoadContextInfo
 nsICacheStorage
 ---------------
 
--  `nsICacheStorage.idl (searchfox) <https://searchfox.org/firefox-main/source/netwerk/cache2/nsICacheStorage.idl>`_
+-  :searchfox:`nsICacheStorage.idl (searchfox) <netwerk/cache2/nsICacheStorage.idl>`
 
 -  Obtained from call to one of the ``*Storage`` methods on
    :ref:`nsICacheStorageService <nsICacheStorageService>`.
@@ -120,7 +119,7 @@ nsICacheStorage
 nsICacheEntryOpenCallback
 -------------------------
 
--  `nsICacheEntryOpenCallback.idl (searchfox) <https://searchfox.org/firefox-main/source/netwerk/cache2/nsICacheEntryOpenCallback.idl>`_
+-  :searchfox:`nsICacheEntryOpenCallback.idl (searchfox) <netwerk/cache2/nsICacheEntryOpenCallback.idl>`
 
 -  The result of ``nsICacheStorage.asyncOpenURI`` is always and only
    sent to callbacks on this interface.
@@ -145,7 +144,7 @@ nsICacheEntryOpenCallback
 nsICacheEntry
 -------------
 
--  `nsICacheEntry.idl (searchfox) <https://searchfox.org/firefox-main/source/netwerk/cache2/nsICacheEntry.idl>`_
+-  :searchfox:`nsICacheEntry.idl (searchfox) <netwerk/cache2/nsICacheEntry.idl>`
 
 -  Obtained asynchronously or pseudo-asynchronously by a call to
    ``nsICacheStorage.asyncOpenURI``.
diff --git a/netwerk/docs/http/lifecycle.rst b/netwerk/docs/http/lifecycle.rst
index 8cd5f414a50e..061cf2dcce83 100644
--- a/netwerk/docs/http/lifecycle.rst
+++ b/netwerk/docs/http/lifecycle.rst
@@ -7,26 +7,53 @@ HTTP requests in Firefox go through several steps.  Each piece of the request me
 What is Available When
 ----------------------
 
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-| Data                  | When it's available                               | Sample JS code                        | Interfaces             | Test code                     |
-+=======================+===================================================+=======================================+========================+===============================+
-| HTTP request method   | *http-on-modify-request* observer notification    | channel.requestMethod                 | nsIHttpChannel_        |                               |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-| HTTP request URI      | *http-on-modify-request* observer notification    | channel.URI                           | nsIChannel_            |                               |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-| HTTP request headers  | *http-on-modify-request* observer notification    | channel.visitRequestHeaders(visitor)  | nsIHttpChannel_        |                               |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-| HTTP request body     | *http-on-modify-request* observer notification    | channel.uploadStream                  | nsIUploadChannel_      |                               |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-|| HTTP response status || *http-on-examine-response* observer notification || channel.responseStatus               || nsIHttpChannel_       || test_basic_functionality.js_ |
-||                      ||                                                  || channel.responseStatusText           ||                       ||                              |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-| HTTP response headers | *http-on-examine-response* observer notification  | channel.visitResponseHeaders(visitor) | nsIHttpChannel_        |                               |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
-|| HTTP response body   || *onStopRequest* via stream listener tee          || See below                            || nsITraceableChannel_  || test_traceable_channel.js_   |
-||                      ||                                                  ||                                      || nsIStreamListenerTee_ ||                              |
-||                      ||                                                  ||                                      || nsIPipe_              ||                              |
-+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
+.. list-table::
+   :header-rows: 1
+   :widths: auto
+
+   * - Data
+     - When it's available
+     - Sample JS code
+     - Interfaces
+     - Test code
+   * - HTTP request method
+     - *http-on-modify-request* observer notification
+     - channel.requestMethod
+     - :searchfox:`nsIHttpChannel <netwerk/protocol/http/nsIHttpChannel.idl>`
+     -
+   * - HTTP request URI
+     - *http-on-modify-request* observer notification
+     - channel.URI
+     - :searchfox:`nsIChannel <netwerk/base/nsIChannel.idl>`
+     -
+   * - HTTP request headers
+     - *http-on-modify-request* observer notification
+     - channel.visitRequestHeaders(visitor)
+     - :searchfox:`nsIHttpChannel <netwerk/protocol/http/nsIHttpChannel.idl>`
+     -
+   * - HTTP request body
+     - *http-on-modify-request* observer notification
+     - channel.uploadStream
+     - :searchfox:`nsIUploadChannel <netwerk/base/nsIUploadChannel.idl>`
+     -
+   * - HTTP response status
+     - *http-on-examine-response* observer notification
+     - | channel.responseStatus
+       | channel.responseStatusText
+     - :searchfox:`nsIHttpChannel <netwerk/protocol/http/nsIHttpChannel.idl>`
+     - :searchfox:`test_basic_functionality.js <netwerk/test/httpserver/test/test_basic_functionality.js>`
+   * - HTTP response headers
+     - *http-on-examine-response* observer notification
+     - channel.visitResponseHeaders(visitor)
+     - :searchfox:`nsIHttpChannel <netwerk/protocol/http/nsIHttpChannel.idl>`
+     -
+   * - HTTP response body
+     - *onStopRequest* via stream listener tee
+     - See below
+     - | :searchfox:`nsITraceableChannel <netwerk/base/nsITraceableChannel.idl>`
+       | :searchfox:`nsIStreamListenerTee <netwerk/base/nsIStreamListenerTee.idl>`
+       | :searchfox:`nsIPipe <xpcom/io/nsIPipe.idl>`
+     - :searchfox:`test_traceable_channel.js <netwerk/test/unit/test_traceable_channel.js>`
 
 The Request: http-on-modify-request
 -----------------------------------
@@ -48,7 +75,7 @@ Attaching a listener for a request is pretty simple::
 
   Services.obs.addObserver(observer, "http-on-modify-request", false);
 
-See nsIObserverService_ for the details.
+See :searchfox:`nsIObserverService <xpcom/ds/nsIObserverService.idl>` for the details.
 
 The request method and URI are immediately available at this time.  Request headers are trivially easy to get::
 
@@ -75,9 +102,9 @@ The request method and URI are immediately available at this time.  Request head
   const visitor = new HeaderVisitor(requestHeaders);
   channel.visitRequestHeaders(visitor);
 
-This is also the time to set request headers, if you need to.  The method for that on the nsIHttpChannel_ interface is `channel.setRequestHeader(header, value);`
+This is also the time to set request headers, if you need to.  The method for that on the :searchfox:`nsIHttpChannel <netwerk/protocol/http/nsIHttpChannel.idl>` interface is `channel.setRequestHeader(header, value);`
 
-Most HTTP requests don't have a body, as they are GET requests.  POST requests often have them, though.  As the nsIUploadChannel_ documentation indicates, the body of most HTTP requests is available via a seekable stream (nsISeekableStream_).  So you can simply capture the body stream and its current position, to revisit it later.  network-helper.js_ has code to read the request body.
+Most HTTP requests don't have a body, as they are GET requests.  POST requests often have them, though.  As the :searchfox:`nsIUploadChannel <netwerk/base/nsIUploadChannel.idl>` documentation indicates, the body of most HTTP requests is available via a seekable stream (:searchfox:`nsISeekableStream <xpcom/io/nsISeekableStream.idl>`).  So you can simply capture the body stream and its current position, to revisit it later.  :searchfox:`network-helper.js <devtools/shared/webconsole/network-helper.js>` has code to read the request body.
 
 The Response: http-on-examine-response
 --------------------------------------
@@ -175,7 +202,7 @@ Here's some sample code to illustrate what you need::
     }
   }
 
-test_traceable_channel.js_ does essentially this.
+:searchfox:`test_traceable_channel.js <netwerk/test/unit/test_traceable_channel.js>` does essentially this.
 
 Character Encodings and Compression
 -----------------------------------
@@ -203,18 +230,4 @@ Order of Operations
 Useful Code Samples and References
 ----------------------------------
 
-- nsIHttpProtocolHandler_ defines a lot of observer topics, and has a lot of details.
-
-.. _nsIHttpChannel: https://searchfox.org/firefox-main/source/netwerk/protocol/http/nsIHttpChannel.idl
-.. _nsIChannel: https://searchfox.org/firefox-main/source/netwerk/base/nsIChannel.idl
-.. _nsIUploadChannel: https://searchfox.org/firefox-main/source/netwerk/base/nsIUploadChannel.idl
-.. _nsITraceableChannel: https://searchfox.org/firefox-main/source/netwerk/base/nsITraceableChannel.idl
-.. _nsISeekableStream: https://searchfox.org/firefox-main/source/xpcom/io/nsISeekableStream.idl
-.. _nsIObserverService: https://searchfox.org/firefox-main/source/xpcom/ds/nsIObserverService.idl
-.. _nsIHttpProtocolHandler: https://searchfox.org/firefox-main/source/netwerk/protocol/http/nsIHttpProtocolHandler.idl
-.. _nsIStreamListenerTee: https://searchfox.org/firefox-main/source/netwerk/base/nsIStreamListenerTee.idl
-.. _nsIPipe: https://searchfox.org/firefox-main/source/xpcom/io/nsIPipe.idl
-
-.. _test_basic_functionality.js: https://searchfox.org/firefox-main/source/netwerk/test/httpserver/test/test_basic_functionality.js
-.. _test_traceable_channel.js: https://searchfox.org/firefox-main/source/netwerk/test/unit/test_traceable_channel.js
-.. _network-helper.js: https://searchfox.org/firefox-main/source/devtools/shared/webconsole/network-helper.js
+- :searchfox:`nsIHttpProtocolHandler <netwerk/protocol/http/nsIHttpProtocolHandler.idl>` defines a lot of observer topics, and has a lot of details.
diff --git a/netwerk/docs/http_server_for_testing.rst b/netwerk/docs/http_server_for_testing.rst
index 429c99b9b611..d3ad60ee4d39 100644
--- a/netwerk/docs/http_server_for_testing.rst
+++ b/netwerk/docs/http_server_for_testing.rst
@@ -29,7 +29,7 @@ Where You Can Use It
 The server is written primarily for use from ``xpcshell``-based
 tests, and it can be used as an inline script or as an XPCOM component. The
 Mochitest framework also uses it to serve its tests, and
-`reftests <https://searchfox.org/firefox-main/source/layout/tools/reftest/README.txt>`__
+:searchfox:`reftests <layout/tools/reftest/README.txt>`
 can optionally use it when their behavior is dependent upon specific
 HTTP header values.
 
@@ -60,7 +60,7 @@ The best and first place you should look for documentation is
 comprehensive and detailed, and it should be enough to figure out how to
 make the server do what you want. I also suggest taking a look at the
 less-comprehensive server
-`README <https://searchfox.org/firefox-main/source/netwerk/test/httpserver/README>`__,
+:searchfox:`README <netwerk/test/httpserver/README>`,
 although the IDL should usually be sufficient.
 
 Running the Server
@@ -112,7 +112,7 @@ because the error-dispatch mechanism doesn't currently accommodate doing
 so and partly because exposing errors in a real server could make it
 easier to exploit them. If you don't know why the server is acting a
 particular way, edit
-`httpd.sys.mjs <https://searchfox.org/firefox-main/source/netwerk/test/httpserver/httpd.sys.mjs>`__
+:searchfox:`httpd.sys.mjs <netwerk/test/httpserver/httpd.sys.mjs>`
 and change the value of ``DEBUG`` to ``true``. This will cause the
 server to print information about the processing of requests (and errors
 encountered doing so) to the console, and it's usually not difficult to
diff --git a/python/mach/docs/usage.rst b/python/mach/docs/usage.rst
index 8b4f837ad787..2dffa37340e3 100644
--- a/python/mach/docs/usage.rst
+++ b/python/mach/docs/usage.rst
@@ -147,4 +147,4 @@ The settings file follows the ``ini`` format, e.g:
     default = fuzzy
 
 
-.. _bash completion: https://searchfox.org/firefox-main/source/python/mach/bash-completion.sh
+.. _bash completion: :searchfox:`python/mach/bash-completion.sh`
diff --git a/python/mozperftest/perfdocs/vision.rst b/python/mozperftest/perfdocs/vision.rst
index fd7985e21799..cff87102fe46 100644
--- a/python/mozperftest/perfdocs/vision.rst
+++ b/python/mozperftest/perfdocs/vision.rst
@@ -21,9 +21,9 @@ not on all platforms and was specific to the Browsertime framework.
 
 `mozperftest` currently provides the `mach perftest` command, that will scan
 for all tests that are declared in ini files such as
-https://searchfox.org/firefox-main/source/netwerk/test/perf/perftest.toml and
+:searchfox:`netwerk/test/perf/perftest.toml` and
 registered under **PERFTESTS_MANIFESTS** in `moz.build` files such as
-https://searchfox.org/firefox-main/source/netwerk/test/moz.build#17
+:searchfox:`netwerk/test/moz.build#17`
 
 The framework loads perf tests and reads its metadata, that can be declared
 within the test. We have a parser that is currently able to recognize and load
diff --git a/python/mozperftest/perfdocs/writing.rst b/python/mozperftest/perfdocs/writing.rst
index b01901f88bb8..691564d67ae6 100644
--- a/python/mozperftest/perfdocs/writing.rst
+++ b/python/mozperftest/perfdocs/writing.rst
@@ -34,7 +34,7 @@ Most tests are registered using tests manifests and the **PERFTESTS_MANIFESTS**
 variable in `moz.build` files - it's good practice to name this file
 `perftest.toml`. **This doesn't apply to mochitest tests**, they should use the manifest variable of the respective flavour/subsuite that the test is running in.
 
-Example of such a file: https://searchfox.org/firefox-main/source/testing/performance/perftest.toml
+Example of such a file: :searchfox:`testing/performance/perftest.toml`
 
 
 XPCShell
@@ -54,9 +54,9 @@ Here's an example of such a metrics call::
 XPCShell Tests in CI
 ^^^^^^^^^^^^^^^^^^^^
 
-To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable `found here <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/python/mozperftest/mozperftest/utils.py#299>`_. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.xpcshell.tests.tar.zst`` archive from the build task and search for your test file in it.
+To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable :searchfox:`found here <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:python/mozperftest/mozperftest/utils.py#299>`. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.xpcshell.tests.tar.zst`` archive from the build task and search for your test file in it.
 
-The XPCShell test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. `See here for an example <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/toolkit/components/ml/tests/browser/perftest.toml#7>`_.
+The XPCShell test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. :searchfox:`See here for an example <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:toolkit/components/ml/tests/browser/perftest.toml#7>`.
 
 Mochitest
 ---------
@@ -121,9 +121,9 @@ Only the GeckoView Test Runner, and GeckoView Example are currently supported in
 Mochitest Tests in CI
 ^^^^^^^^^^^^^^^^^^^^^
 
-To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable `found here <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/python/mozperftest/mozperftest/utils.py#299>`_. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.mochitest.tests.tar.zst`` archive from the build task and search for your test file in it.
+To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable :searchfox:`found here <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:python/mozperftest/mozperftest/utils.py#299>`. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.mochitest.tests.tar.zst`` archive from the build task and search for your test file in it.
 
-The Mochitest test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. `See here for an example <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/toolkit/components/ml/tests/browser/perftest.toml#7>`_.
+The Mochitest test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. :searchfox:`See here for an example <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:toolkit/components/ml/tests/browser/perftest.toml#7>`.
 
 Mochitest Android Tests in CI
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -265,7 +265,7 @@ A Python module can be used to run functions during a run lifecycle. Available h
 
 - **before_iterations(args)** runs before everything is started. Gets the args, which
   can be changed. The **args** argument also contains a **virtualenv** variable that
-  can be used for installing Python packages (e.g. through `install_package <https://searchfox.org/firefox-main/source/python/mozperftest/mozperftest/utils.py#115-144>`_).
+  can be used for installing Python packages (e.g. through :searchfox:`install_package <python/mozperftest/mozperftest/utils.py#115-144>`).
 - **before_runs(env)** runs before the test is launched. Can be used to
   change the running environment.
 - **after_runs(env)** runs after the test is done.
diff --git a/services/sync/docs/engines.rst b/services/sync/docs/engines.rst
index 7cbca97f00e5..cf1ca2b58af6 100644
--- a/services/sync/docs/engines.rst
+++ b/services/sync/docs/engines.rst
@@ -3,7 +3,7 @@ The Sync engines in the tree
 ============================
 
 Unless otherwise specified, the engine implementations can be found
-`here <https://searchfox.org/firefox-main/source/services/sync/modules/engines>`_
+:searchfox:`here <services/sync/modules/engines>`
 
 Please read the :doc:`overview`.
 
@@ -80,7 +80,7 @@ are open on other devices. There's no database - if we haven't synced yet we
 don't know what other tabs are open, and when we do know, the list is just
 stored in memory.
 
-The `SyncedTabs module <https://searchfox.org/firefox-main/source/services/sync/modules/SyncedTabs.sys.mjs>`_
+The :searchfox:`SyncedTabs module <services/sync/modules/SyncedTabs.sys.mjs>`
 is the main interface the browser uses to get the list of tabs from other
 devices.
 
@@ -111,7 +111,7 @@ treat them as a single engine in practice.
 
 As a result, only a shim is in the `services/sync/modules/engines/` directory,
 while the actual logic is
-`next to the storage implementation <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/FormAutofillSync.sys.mjs>`_.
+:searchfox:`next to the storage implementation <toolkit/components/formautofill/FormAutofillSync.sys.mjs>`.
 
 This engine has a unique twist on the "mirror" concept described above -
 whenever a change is made to a fields, the original value of the field is
diff --git a/services/sync/docs/overview.rst b/services/sync/docs/overview.rst
index 4a459f63e252..058299807a4e 100644
--- a/services/sync/docs/overview.rst
+++ b/services/sync/docs/overview.rst
@@ -39,7 +39,7 @@ the server, so it knows how to grab just changed records and how to pass them
 off to the ``store`` so the actual underlying storage can be updated.
 
 All of the above parts were typically in the
-`services/sync/modules/engines directory <https://searchfox.org/firefox-main/source/services/sync/modules/engines>`_
+:searchfox:`services/sync/modules/engines directory <services/sync/modules/engines>`
 directory and decoupled from the data they were syncing.
 
 
diff --git a/services/sync/docs/rust-engines.rst b/services/sync/docs/rust-engines.rst
index ea081fa3ac08..251890c48421 100644
--- a/services/sync/docs/rust-engines.rst
+++ b/services/sync/docs/rust-engines.rst
@@ -8,7 +8,7 @@ The bridged-engine
 ==================
 
 Because Rust engines still need to work with the existing Sync infrastructure,
-there's the concept of a `bridged-engine <https://searchfox.org/firefox-main/source/services/sync/modules/bridged_engine.js>`_.
+there's the concept of a :searchfox:`bridged-engine <services/sync/modules/bridged_engine.js>`.
 In short, this is just a shim between the existing
-`Sync Service <https://searchfox.org/firefox-main/source/services/sync/modules/service.js>`_
+:searchfox:`Sync Service <services/sync/modules/service.js>`
 and the Rust code.
diff --git a/taskcluster/docs/kinds/test.rst b/taskcluster/docs/kinds/test.rst
index bdb5bbea8c86..0d4c81b942c9 100644
--- a/taskcluster/docs/kinds/test.rst
+++ b/taskcluster/docs/kinds/test.rst
@@ -41,7 +41,7 @@ Variants
 Sometimes we want to run the same tests under a different Firefox context,
 usually this means with a pref set. The concept of ``variants`` was invented to
 handle this use case. A variant is a stanza of configuration that can be merged
-into each test definition. Variants are defined in the `variants.yml`_ file.
+into each test definition. Variants are defined in the :searchfox:`variants.yml <taskcluster/kinds/test/variants.yml>` file.
 See this file for an up to date list of active variants and the pref(s) they
 set.
 
@@ -108,7 +108,7 @@ Expired Variants
 ~~~~~~~~~~~~~~~~
 Ideally, when a variant is not needed anymore, it should be dropped (even if it
 has not expired). If you need to extend the expiration date, you can submit a
-patch to modify the expiration date in the `variants.yml`_ file. Variants will
+patch to modify the expiration date in the :searchfox:`variants.yml <taskcluster/kinds/test/variants.yml>` file. Variants will
 not be scheduled to run after the expiration date.
 
 If an expired variant is not dropped, the triage owner of the component will be
@@ -120,7 +120,6 @@ manifest conditions pending the triage owner / manager to review.
 Please subscribe to alerts from `firefox-ci <https://groups.google.com/a/mozilla.com/g/firefox-ci>`
 group in order to be aware of changes to the CI, scheduling, or the policy.
 
-.. _variants.yml: https://searchfox.org/firefox-main/source/taskcluster/kinds/test/variants.yml
 .. _json-e: https://json-e.js.org/
 
 
diff --git a/taskcluster/docs/optimization/index.rst b/taskcluster/docs/optimization/index.rst
index 07c7d06a8f5b..422a91968a82 100644
--- a/taskcluster/docs/optimization/index.rst
+++ b/taskcluster/docs/optimization/index.rst
@@ -15,6 +15,4 @@ Other Strategies
 ----------------
 
 There are many other undocumented strategies available here. See the
-`taskcluster/gecko_taskgraph/optimize`_ module for more available strategies.
-
-.. _taskcluster/gecko_taskgraph/optimize: https://searchfox.org/firefox-main/source/taskcluster/gecko_taskgraph/optimize
+:searchfox:`taskcluster/gecko_taskgraph/optimize` module for more available strategies.
diff --git a/taskcluster/docs/release-promotion-action.rst b/taskcluster/docs/release-promotion-action.rst
index 720d6964bfaf..e8b4de91872d 100644
--- a/taskcluster/docs/release-promotion-action.rst
+++ b/taskcluster/docs/release-promotion-action.rst
@@ -5,14 +5,14 @@ The release promotion action is how Releng triggers `release promotion`_
 taskgraphs. The one action covers all release promotion needs: different
 *flavors* allow for us to trigger the different :ref:`release promotion phases`
 for each product. The input schema and release promotion flavors are defined in
-the `release promotion action`_.
+the :searchfox:`release promotion action <taskcluster/gecko_taskgraph/actions/release_promotion.py>`.
 
 .. _snowman model:
 
 The snowman model
 -----------------
 
-The `release promotion action`_ allows us to chain multiple taskgraphs (aka graphs, aka task groups) together.
+The :searchfox:`release promotion action <taskcluster/gecko_taskgraph/actions/release_promotion.py>` allows us to chain multiple taskgraphs (aka graphs, aka task groups) together.
 Essentially, we're using `optimization`_ logic to replace task labels in the
 current taskgraph with task IDs from the previous taskgraph(s).
 
@@ -84,7 +84,7 @@ specifying kinds to rebuild.
 Release promotion action mechanics
 ----------------------------------
 
-There are a number of inputs defined in the `release promotion action`_. Among these are the ``previous_graph_ids``, which is an ordered list of taskGroupIds of the task groups that we want to build our task group, off of. In the :ref:`snowman model`, these define the already-built portions of the snowman.
+There are a number of inputs defined in the :searchfox:`release promotion action <taskcluster/gecko_taskgraph/actions/release_promotion.py>`. Among these are the ``previous_graph_ids``, which is an ordered list of taskGroupIds of the task groups that we want to build our task group, off of. In the :ref:`snowman model`, these define the already-built portions of the snowman.
 
 The action downloads the ``parameters.yml`` from the initial ``previous_graph_id``, which matches the decision- or action- taskId. (See :ref:`taskid vs taskgroupid`.) This is most likely the decision task of the revision to promote, which is generally the same revision the release promotion action is run against.
 
@@ -104,7 +104,7 @@ We've added ``_rc`` suffix flavors, to deal with special RC behavior around roll
 
 We are planning on adding ``_partners`` suffix flavors, to allow for creating partner repacks off-cycle.
 
-The various flavors are defined in the `release promotion action`_.
+The various flavors are defined in the :searchfox:`release promotion action <taskcluster/gecko_taskgraph/actions/release_promotion.py>`.
 
 Triggering the release promotion action via Treeherder
 ------------------------------------------------------
@@ -143,16 +143,15 @@ The full command for a ``promote_firefox`` test might look like::
         -p /src/gecko/params/maple-promote-firefox.yml \
         release_promotion_action > ../promote.json
 
-The input file (in the above example, that would be ``/src/gecko/params/promote_firefox.yml``), contains the action inputs. The input schema is defined in the `release promotion action`_. Previous example inputs are embedded in previous promotion task group action task definitions (``task.extra.action.input``).
+The input file (in the above example, that would be ``/src/gecko/params/promote_firefox.yml``), contains the action inputs. The input schema is defined in the :searchfox:`release promotion action <taskcluster/gecko_taskgraph/actions/release_promotion.py>`. Previous example inputs are embedded in previous promotion task group action task definitions (``task.extra.action.input``).
 
 The ``parameters.yml`` file is downloadable from a previous decision or action task.
 
 .. _release promotion: release-promotion.html
 .. _optimization: optimization.html
 .. _kinds: kinds.html
-.. _release promotion action: https://searchfox.org/firefox-main/source/taskcluster/gecko_taskgraph/actions/release_promotion.py
 .. _Treeherder: https://treeherder.mozilla.org
 .. _Release Promotion Projects: https://searchfox.org/mozilla-central/search?q=RELEASE_PROMOTION_PROJECTS&path=taskcluster/gecko_taskgraph/util/attributes.py
 .. _releasewarrior docs: https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/release-promotion/desktop/howto.md#how
 .. _trigger_action.py: https://searchfox.org/build-central/source/tools/buildfarm/release/trigger_action.py#118
-.. _.taskcluster.yml: https://searchfox.org/firefox-main/source/.taskcluster.yml
+.. _.taskcluster.yml: :searchfox:`.taskcluster.yml`
diff --git a/taskcluster/docs/taskgraph.rst b/taskcluster/docs/taskgraph.rst
index 8a716b2962f4..82d001d8cab4 100644
--- a/taskcluster/docs/taskgraph.rst
+++ b/taskcluster/docs/taskgraph.rst
@@ -32,7 +32,7 @@ Kinds
 Generation starts with "kinds". These are yaml files that denote groupings of
 tasks that are loosely related to one another. For example, in Gecko there are
 ``build`` and ``test`` kinds. Each kind has its own directory under
-`taskcluster/kinds`_ which contains a ``kind.yml`` file.
+:searchfox:`taskcluster/kinds` which contains a ``kind.yml`` file.
 
 For more information on kinds, see Taskgraph's `kind documentation`_. For a
 list of available kinds in ``mozilla-central``, see the :doc:`kinds reference
@@ -115,8 +115,7 @@ Graph Configuration
 There are several configuration settings that are pertain to the entire
 taskgraph. These are specified in :file:`config.yml` at the root of the
 taskgraph configuration (typically :file:`taskcluster`). The available
-settings are documented inline in `taskcluster/gecko_taskgraph/config.py
-<https://searchfox.org/firefox-main/source/taskcluster/gecko_taskgraph/config.py>`_.
+settings are documented inline in :searchfox:`taskcluster/gecko_taskgraph/config.py`.
 
 .. _taskgraph-trust-domain:
 
@@ -131,7 +130,6 @@ For more information, see Taskgraph's `actions documentation`_.
 
 .. _graph generation documentation: https://taskcluster-taskgraph.readthedocs.io/en/latest/concepts/task-graphs.html
 .. _this guide: https://taskcluster-taskgraph.readthedocs.io/en/latest/howto/run-locally.html
-.. _taskcluster/kinds: https://searchfox.org/firefox-main/source/taskcluster/kinds
 .. _kind documentation: https://taskcluster-taskgraph.readthedocs.io/en/latest/concepts/kind.html
 .. _loader documentation: https://taskcluster-taskgraph.readthedocs.io/en/latest/concepts/loading.html
 .. _transforms documentation: https://taskcluster-taskgraph.readthedocs.io/en/latest/concepts/transforms.html
diff --git a/taskcluster/docs/transforms/index.rst b/taskcluster/docs/transforms/index.rst
index 7b4e9560bfa8..b96455b0c35c 100644
--- a/taskcluster/docs/transforms/index.rst
+++ b/taskcluster/docs/transforms/index.rst
@@ -16,8 +16,7 @@ Other Transforms
 ----------------
 
 There are tons of transforms that are not documented here. Consult the source
-files under `taskcluster/gecko_taskgraph/transforms`_ which provide lots of
+files under :searchfox:`taskcluster/gecko_taskgraph/transforms` which provide lots of
 additional detail, both in the code itself and in comments and docstrings.
 
 .. _Transforms: https://taskcluster-taskgraph.readthedocs.io/en/latest/concepts/transforms.html
-.. _taskcluster/gecko_taskgraph/transforms: https://searchfox.org/firefox-main/source/taskcluster/gecko_taskgraph/transforms
diff --git a/testing/docs/automated-testing/index.rst b/testing/docs/automated-testing/index.rst
index b0f380ea9c53..c0c16141f430 100644
--- a/testing/docs/automated-testing/index.rst
+++ b/testing/docs/automated-testing/index.rst
@@ -285,8 +285,7 @@ that need it as possible. Here are some options:
 
 -  If the test runs in chrome scope (e.g mochitest chrome or
    browser-chrome), you can use
-   `Services.prefs
-   <https://searchfox.org/firefox-main/source/modules/libpref/nsIPrefBranch.idl>`__
+   :searchfox:`Services.prefs <modules/libpref/nsIPrefBranch.idl>`
    to set the prefs in your test's setup function. Be sure to reset the
    pref back to its original value during teardown!
 
@@ -319,14 +318,12 @@ Setting prefs that apply to the entire suite
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Most test suites define prefs in user.js files that live under
-`testing/profiles
-<https://searchfox.org/firefox-main/source/testing/profiles>`__.
+:searchfox:`testing/profiles`.
 Each directory is a profile that contains a ``user.js`` file with a
 number of prefs defined in it. Test suites will then merge one or more
 of these basic profiles into their own profile at runtime. To see which
 profiles apply to which test suites, you can inspect
-`testing/profiles/profiles.json
-<https://searchfox.org/firefox-main/source/testing/profiles/profiles.json>`__.
+:searchfox:`testing/profiles/profiles.json`.
 Profiles at the beginning of the list get overridden by profiles at the
 end of the list.
 
@@ -345,8 +342,7 @@ was created:
 .. container:: blockIndicator note
 
    **Note:** JS engine tests do not use testing/profiles yet, instead
-   `set prefs
-   here <https://searchfox.org/firefox-main/source/js/src/tests/user.js>`__.
+   :searchfox:`set prefs here <js/src/tests/user.js>`.
 
 Adding New Context to Skip Conditions
 -------------------------------------
diff --git a/testing/docs/automated-testing/manifest-sandbox.rst b/testing/docs/automated-testing/manifest-sandbox.rst
index dad5c446e270..4f97c72234a6 100644
--- a/testing/docs/automated-testing/manifest-sandbox.rst
+++ b/testing/docs/automated-testing/manifest-sandbox.rst
@@ -25,14 +25,12 @@ How to Add a Keyword
 
 Where to add the new key depends on what type of information it is.
 
-1. If the key is a property of the build, you'll need to patch `this file
-   <https://searchfox.org/firefox-main/source/python/mozbuild/mozbuild/mozinfo.py>`_.
+1. If the key is a property of the build, you'll need to patch :searchfox:`this file <python/mozbuild/mozbuild/mozinfo.py>`.
 2. If the key is a property of the test environment, you'll need to patch
    `mozinfo <https://firefox-source-docs.mozilla.org/mozbase/mozinfo.html>`_.
 3. If the key is a runtime configuration, for example based on a pref that is
    passed in via mach or the task configuration, then you'll need to update the
-   individual test harnesses. For example, `this location
-   <https://searchfox.org/mozilla-central/rev/a7e33b7f61e7729e2b1051d2a7a27799f11a5de6/testing/mochitest/runtests.py#3341>`_
+   individual test harnesses. For example, :searchfox:`this location <mozilla-central/rev/a7e33b7f61e7729e2b1051d2a7a27799f11a5de6:testing/mochitest/runtests.py#3341>`
    for Mochitest. Currently there is no shared location to set runtime keys
    across test harnesses.
 
@@ -55,16 +53,14 @@ In this case, ``cocoaWidget`` and ``isDebugbuild`` are booleans.
 
 The test will download the build's ``target.mozinfo.json``, then in addition to
 the mozinfo, will query runtime info from the browser to build a sandbox of
-keywords. This logic lives in `manifest.sys.mjs
-<https://searchfox.org/firefox-main/source/layout/tools/reftest/manifest.sys.mjs#439>`__.
+keywords. This logic lives in :searchfox:`manifest.sys.mjs <layout/tools/reftest/manifest.sys.mjs#439>`.
 
 How to Add a Keyword
 ~~~~~~~~~~~~~~~~~~~~
 
 Where to add the new key depends on what type of information it is.
 
-1. If the key is a property of the build, you'll need to patch `this file
-   <https://searchfox.org/firefox-main/source/python/mozbuild/mozbuild/mozinfo.py>`_.
+1. If the key is a property of the build, you'll need to patch :searchfox:`this file <python/mozbuild/mozbuild/mozinfo.py>`.
 2. If the key is a property of the test environment or a runtime configuration,
    then you'll need need to update manifest sandbox.
 
diff --git a/testing/docs/chrome-tests/index.rst b/testing/docs/chrome-tests/index.rst
index 70f23156c052..bed12935a0b2 100644
--- a/testing/docs/chrome-tests/index.rst
+++ b/testing/docs/chrome-tests/index.rst
@@ -89,12 +89,11 @@ running with chrome privileges, i.e. code and UI are referenced by
 
 The comparison functions are identical to those supported by Mochitests,
 see how the comparison functions work
-in the Mochitest documentation for more details. The `EventUtils helper
-functions <https://searchfox.org/firefox-main/source/testing/mochitest/tests/SimpleTest/EventUtils.js>`__
+in the Mochitest documentation for more details. The :searchfox:`EventUtils helper functions <testing/mochitest/tests/SimpleTest/EventUtils.js>`
 are available on the "EventUtils" object defined in the global scope.
 
 The test suite also supports asynchronous tests.
-To use these asynchronous tests, please use the `add_task() <https://searchfox.org/firefox-main/source/testing/mochitest/tests/SimpleTest/SimpleTest.js#2025>`__ functionality.
+To use these asynchronous tests, please use the :searchfox:`add_task() <testing/mochitest/tests/SimpleTest/SimpleTest.js#2025>` functionality.
 
 Any exceptions thrown while running a test will be caught and reported
 in the test output as a failure. Exceptions thrown outside of the test's
diff --git a/testing/docs/tests-for-new-config/index.rst b/testing/docs/tests-for-new-config/index.rst
index 9c500888c732..0089a8648b8a 100644
--- a/testing/docs/tests-for-new-config/index.rst
+++ b/testing/docs/tests-for-new-config/index.rst
@@ -109,9 +109,9 @@ denote which tests to run on that variant.
 Using our example of ``windows_1903``, this would be a new worker type that
 would require these edits:
 
- * `transforms/tests.py <https://searchfox.org/firefox-main/source/taskcluster/taskgraph/transforms/tests.py#97>`__ (duplicate windows 10 entries)
- * `test-platforms.py <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/test-platforms.yml#229>`__ (copy windows10 debug/opt/shippable/asan entries and make win10_1903)
- * `test-sets.py <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/test-sets.yml#293>`__ (ideally you need nothing, otherwise copy ``windows-tests`` and edit the test list)
+ * :searchfox:`transforms/tests.py <taskcluster/taskgraph/transforms/tests.py#97>` (duplicate windows 10 entries)
+ * :searchfox:`test-platforms.py <taskcluster/kinds/test/test-platforms.yml#229>` (copy windows10 debug/opt/shippable/asan entries and make win10_1903)
+ * :searchfox:`test-sets.py <taskcluster/kinds/test/test-sets.yml#293>` (ideally you need nothing, otherwise copy ``windows-tests`` and edit the test list)
 
 In general this should allow you to have tests scheduled with no custom flags
 in try server and all of these will be scheduled by default on
diff --git a/testing/docs/tests-for-new-config/manual.rst b/testing/docs/tests-for-new-config/manual.rst
index 65ea8b8727ed..1571e5736ac7 100644
--- a/testing/docs/tests-for-new-config/manual.rst
+++ b/testing/docs/tests-for-new-config/manual.rst
@@ -203,9 +203,9 @@ denote which tests to run on that variant.
 Using our example of ``windows_1903``, this would be a new worker type that
 would require these edits:
 
- * `transforms/tests.py <https://searchfox.org/firefox-main/source/taskcluster/taskgraph/transforms/tests.py#97>`__ (duplicate windows 10 entries)
- * `test-platforms.py <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/test-platforms.yml#229>`__ (copy windows10 debug/opt/shippable/asan entries and make win10_1903)
- * `test-sets.py <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/test-sets.yml#293>`__ (ideally you need nothing, otherwise copy ``windows-tests`` and edit the test list)
+ * :searchfox:`transforms/tests.py <taskcluster/taskgraph/transforms/tests.py#97>` (duplicate windows 10 entries)
+ * :searchfox:`test-platforms.py <taskcluster/kinds/test/test-platforms.yml#229>` (copy windows10 debug/opt/shippable/asan entries and make win10_1903)
+ * :searchfox:`test-sets.py <taskcluster/kinds/test/test-sets.yml#293>` (ideally you need nothing, otherwise copy ``windows-tests`` and edit the test list)
 
 In general this should allow you to have tests scheduled with no custom flags
 in try server and all of these will be scheduled by default on
diff --git a/testing/docs/xpcshell/index.rst b/testing/docs/xpcshell/index.rst
index aaeb4660ea45..e712189ea76e 100644
--- a/testing/docs/xpcshell/index.rst
+++ b/testing/docs/xpcshell/index.rst
@@ -572,7 +572,7 @@ Runtime detection
 
 Some tests will want to only execute certain portions on specific
 platforms. Use
-`AppConstants.sys.mjs <https://searchfox.org/mozilla-central/rev/5f0a7ca8968ac5cef8846e1d970ef178b8b76dcc/toolkit/modules/AppConstants.sys.mjs#158>`__
+:searchfox:`AppConstants.sys.mjs <mozilla-central/rev/5f0a7ca8968ac5cef8846e1d970ef178b8b76dcc:toolkit/modules/AppConstants.sys.mjs#158>`
 for determining the platform, for example:
 
 .. code:: js
diff --git a/testing/mozbase/docs/manifestparser.rst b/testing/mozbase/docs/manifestparser.rst
index 170a0bd27a35..f874744b80c6 100644
--- a/testing/mozbase/docs/manifestparser.rst
+++ b/testing/mozbase/docs/manifestparser.rst
@@ -232,7 +232,7 @@ To recap:
 * you can use it however you want or process it further as you need
 
 Tests are denoted by sections in an ``*.toml`` file (see
-https://searchfox.org/firefox-main/source/testing/mozbase/manifestparser/tests/manifest.toml
+:searchfox:`testing/mozbase/manifestparser/tests/manifest.toml`
 ).
 
 Additional manifest files may be included with an `[include:]` directive:
@@ -267,7 +267,7 @@ from TestManifest if more harness-specific customization is desired at
 the manifest level.
 
 See the source code at
-https://searchfox.org/firefox-main/source/testing/mozbase/manifestparser
+:searchfox:`testing/mozbase/manifestparser`
 .
 
 Filtering Manifests
diff --git a/testing/perfdocs/generated/browsertime.rst b/testing/perfdocs/generated/browsertime.rst
index f345ed1b7336..0f2900d70294 100644
--- a/testing/perfdocs/generated/browsertime.rst
+++ b/testing/perfdocs/generated/browsertime.rst
@@ -188,22 +188,19 @@ Similarly for running tp6m (equivalent to tp6 but for mobile) on Firefox for And
    ./mach try perf --full -q "'tp6m 'webextensions"
 
 The set of extensions installed are the ones listed in the ``"addons"`` property of the condprof customization file
-`webext.json`_ from the ``testing/condprofile/condprof/customization/`` directory.
+:searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` from the ``testing/condprofile/condprof/customization/`` directory.
 
 All extensions listed in the ``webext.json`` file are expected to have been predownloaded and included in the ``firefox-addons.tar`` archive
-defined in the CI fetch config named `firefox-addons`_, but they will be automatically downloaded from the url specified in the ``webext.json``
+defined in the CI fetch config named :searchfox:`firefox-addons <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:taskcluster/ci/fetch/browsertime.yml#169-176>`, but they will be automatically downloaded from the url specified in the ``webext.json``
 file if they are not.
 
 In a try push we allow to run jobs on new extension XPI files not part of the firefox-addons.tar archive, the new extension needs to be just
-added in the `webext.json`_ condprof customization file in a patch part of the same stack of patches being pushed to try.
+added in the :searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` condprof customization file in a patch part of the same stack of patches being pushed to try.
 
-On the contrary new extensions added to the `webext.json`_ condprof customization file on mozilla-central patches will require the XPI file to be
-added to the ``firefox-addons.tar`` archive and the `firefox-addons`_ CI fetch config updated accordingly (missing to update the archive will
+On the contrary new extensions added to the :searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` condprof customization file on mozilla-central patches will require the XPI file to be
+added to the ``firefox-addons.tar`` archive and the :searchfox:`firefox-addons <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:taskcluster/ci/fetch/browsertime.yml#169-176>` CI fetch config updated accordingly (missing to update the archive will
 trigger explicit linter errors, :doc:`see condprof-addons linter docs </code-quality/lint/linters/condprof-addons>`).
 
-.. _webext.json: https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/testing/condprofile/condprof/customization/webext.json
-.. _firefox-addons: https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/taskcluster/ci/fetch/browsertime.yml#169-176
-
 TP6-Bench Test
 --------------
 
@@ -286,15 +283,15 @@ Equivalent functionality to the ``--gecko-profile`` flag, i.e. something like ``
 Custom profiling with Raptor-Browsertime
 ----------------------------------------
 
-With browsertime you can now use the exposed start/stop commands of the gecko profiler **and** chrome trace. First, one needs to define the ``expose_browser_profiler`` and ``apps`` variables appropriately in the `test's configuration file <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#9,12>`_
+With browsertime you can now use the exposed start/stop commands of the gecko profiler **and** chrome trace. First, one needs to define the ``expose_browser_profiler`` and ``apps`` variables appropriately in the :searchfox:`test's configuration file <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#9,12>`
 
-If you want to run the test in CI then you will want to ensure you set the ``--extra-profiler-run`` flag in the mozharness extra options for where your test is defined in the `browsertime-desktop yaml file <https://searchfox.org/mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7/taskcluster/ci/test/browsertime-desktop.yml#404-406>`_. Otherwise you can just pass the ``--extra-profiler-run`` flag locally in your command line.
+If you want to run the test in CI then you will want to ensure you set the ``--extra-profiler-run`` flag in the mozharness extra options for where your test is defined in the :searchfox:`browsertime-desktop yaml file <mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7:taskcluster/ci/test/browsertime-desktop.yml#404-406>`. Otherwise you can just pass the ``--extra-profiler-run`` flag locally in your command line.
 
-Both of these steps are required to satisfy the ``_expose_browser_profiler()`` `method <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#241>`_ so that the option, `expose_profiler <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#383-386>`_, is passed into your browsertime script. Finally, it should be as simple as calling the ``start()`` & ``stop()`` commands in your `script <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/browsertime/speedometer3.js#14,30-37,58-65>`_.
+Both of these steps are required to satisfy the ``_expose_browser_profiler()`` :searchfox:`method <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#241>` so that the option, :searchfox:`expose_profiler <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#383-386>`, is passed into your browsertime script. Finally, it should be as simple as calling the ``start()`` & ``stop()`` commands in your :searchfox:`script <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/browsertime/speedometer3.js#14,30-37,58-65>`.
 
-For the gecko profiler, you should also keep in mind these `default parameters <https://searchfox.org/mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7/testing/raptor/raptor/browsertime/base.py#474-495>`_, which you may or may not want to change yourself in your tests configuration file.
+For the gecko profiler, you should also keep in mind these :searchfox:`default parameters <mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7:testing/raptor/raptor/browsertime/base.py#474-495>`, which you may or may not want to change yourself in your tests configuration file.
 
-Likewise, for chrome trace you will want to be aware of `these defaults. <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#646-658>`_
+Likewise, for chrome trace you will want to be aware of :searchfox:`these defaults. <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#646-658>`
 
 Upgrading Browsertime In-Tree
 -----------------------------
@@ -314,7 +311,7 @@ Updating Benchmark Tests
 
 To upgrade any of our benchmark tests, you will need to change the revision used in the test manifest. There are three fields that you have available to use there: ``repository_revision`` to denote the revision, ``repository_branch`` to denote the branch name, and ``repository`` to provide the link of the Github repo that contains the benchmark.
 
-For instance, with Speedometer 3 (sp3), we can update the revision `by changing the repository_revision field found here <https://searchfox.org/mozilla-central/rev/aa3ccd258b64abfd4c5ce56c1f512bc7f65b844c/testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#29>`_. If the change isn't found on the default branch (master/main branch), then you will need to add an entry for ``repository_branch`` to specify this.
+For instance, with Speedometer 3 (sp3), we can update the revision :searchfox:`by changing the repository_revision field found here <mozilla-central/rev/aa3ccd258b64abfd4c5ce56c1f512bc7f65b844c:testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#29>`. If the change isn't found on the default branch (master/main branch), then you will need to add an entry for ``repository_branch`` to specify this.
 
 If the path to the test file changes (the file that is invoked to run the test), then the ``test_url`` will need to be changed.
 
diff --git a/testing/perfdocs/generated/debugging.rst b/testing/perfdocs/generated/debugging.rst
index 1c33720e499b..808d7c331729 100644
--- a/testing/perfdocs/generated/debugging.rst
+++ b/testing/perfdocs/generated/debugging.rst
@@ -71,8 +71,8 @@ To retrieve the console.log() output from the Raptor content 'measure.js' code:
 
 Raptor automatically closes the test tab and the entire browser after test completion; which will close any open debug consoles. In order to have more time to review the console logs, Raptor can be temporarily hacked locally in order to prevent the test tab and browser from being closed. Currently this must be done manually, as follows:
 
-#. In the Raptor web extension runner, comment out the line that closes the test tab in the test clean-up. That line of `code is here <https://searchfox.org/mozilla-central/rev/3c85ea2f8700ab17e38b82d77cd44644b4dae703/testing/raptor/webext/raptor/runner.js#357>`_.
-#. Add a return statement at the top of the Raptor control server method that shuts-down the browser, the browser shutdown `method is here <https://searchfox.org/mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128/testing/raptor/raptor/control_server.py#120>`_.
+#. In the Raptor web extension runner, comment out the line that closes the test tab in the test clean-up. That line of :searchfox:`code is here <mozilla-central/rev/3c85ea2f8700ab17e38b82d77cd44644b4dae703:testing/raptor/webext/raptor/runner.js#357>`.
+#. Add a return statement at the top of the Raptor control server method that shuts-down the browser, the browser shutdown :searchfox:`method is here <mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128:testing/raptor/raptor/control_server.py#120>`.
 
 For **benchmark type tests** (i.e. speedometer, motionmark, etc.) Raptor doesn't inject 'measure.js' into the test page content; instead it injects ':searchfox:`benchmark-relay.js <testing/raptor/webext/raptor/benchmark-relay.js>`' into the benchmark test content. Benchmark-relay is as it sounds; it basically relays the test results coming from the benchmark test, to the Raptor web extension runner. Viewing the console.log() output from benchmark-relay is done the same was as noted for the 'measure.js' content above.
 
diff --git a/testing/perfdocs/generated/telemetry-alerting.rst b/testing/perfdocs/generated/telemetry-alerting.rst
index 59ae6ccd2bf9..0407644ed7d3 100644
--- a/testing/perfdocs/generated/telemetry-alerting.rst
+++ b/testing/perfdocs/generated/telemetry-alerting.rst
@@ -19,7 +19,7 @@ Probe Setup
 .. note::
   Only Windows is currently available for platforms that can be alerted on due to a high number of false positives on Linux, and Mac. Follow `this bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1998552>`_ for progress on this issue. Android is disabled due to other issues and will be looked at `here <https://bugzilla.mozilla.org/show_bug.cgi?id=1976760>`_. Only **timing_distribution** probes are supported with the existing change detection technique.
 
-To enable alerting or monitoring on a telemetry probe, the ``monitor`` field will need to be added to the ``metadata`` section of the probe definition. **This will only work for timing_distribution probes, other probe types are not supported.** `See this probe for an example <https://searchfox.org/mozilla-central/rev/38e462fe13ea42ae6cc391fb36e8b9e82e842b00/netwerk/metrics.yaml#1883-1888>`_. The following provides all possible fields that will be accepted in the ``monitor`` field:
+To enable alerting or monitoring on a telemetry probe, the ``monitor`` field will need to be added to the ``metadata`` section of the probe definition. **This will only work for timing_distribution probes, other probe types are not supported.** :searchfox:`See this probe for an example <mozilla-central/rev/38e462fe13ea42ae6cc391fb36e8b9e82e842b00:netwerk/metrics.yaml#1883-1888>`. The following provides all possible fields that will be accepted in the ``monitor`` field:
 
 .. code-block:: none
 
diff --git a/testing/perfdocs/generated/writing.rst b/testing/perfdocs/generated/writing.rst
index f481c6152bca..691564d67ae6 100644
--- a/testing/perfdocs/generated/writing.rst
+++ b/testing/perfdocs/generated/writing.rst
@@ -54,9 +54,9 @@ Here's an example of such a metrics call::
 XPCShell Tests in CI
 ^^^^^^^^^^^^^^^^^^^^
 
-To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable `found here <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/python/mozperftest/mozperftest/utils.py#299>`_. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.xpcshell.tests.tar.zst`` archive from the build task and search for your test file in it.
+To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable :searchfox:`found here <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:python/mozperftest/mozperftest/utils.py#299>`. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.xpcshell.tests.tar.zst`` archive from the build task and search for your test file in it.
 
-The XPCShell test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. `See here for an example <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/toolkit/components/ml/tests/browser/perftest.toml#7>`_.
+The XPCShell test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. :searchfox:`See here for an example <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:toolkit/components/ml/tests/browser/perftest.toml#7>`.
 
 Mochitest
 ---------
@@ -121,9 +121,9 @@ Only the GeckoView Test Runner, and GeckoView Example are currently supported in
 Mochitest Tests in CI
 ^^^^^^^^^^^^^^^^^^^^^
 
-To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable `found here <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/python/mozperftest/mozperftest/utils.py#299>`_. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.mochitest.tests.tar.zst`` archive from the build task and search for your test file in it.
+To run your test in CI, you may need to modify the ``_TRY_MAPPING`` variable :searchfox:`found here <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:python/mozperftest/mozperftest/utils.py#299>`. This will allow us to find your test file in CI, and is needed because the file mappings differ from local runs. The mapping maps the top-level folder of the test to it's location in CI. To find this location/mapping, download the ``target.mochitest.tests.tar.zst`` archive from the build task and search for your test file in it.
 
-The Mochitest test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. `See here for an example <https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/toolkit/components/ml/tests/browser/perftest.toml#7>`_.
+The Mochitest test that is written can also be run as a unit test, however, if this is not desired, set the `disabled = reason` flag in the test TOML file to prevent it from running there. :searchfox:`See here for an example <mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0:toolkit/components/ml/tests/browser/perftest.toml#7>`.
 
 Mochitest Android Tests in CI
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/testing/performance/mach-try-perf/perfdocs/index.rst b/testing/performance/mach-try-perf/perfdocs/index.rst
index b99eeaef3ecc..bb9b2ca16c79 100644
--- a/testing/performance/mach-try-perf/perfdocs/index.rst
+++ b/testing/performance/mach-try-perf/perfdocs/index.rst
@@ -341,7 +341,7 @@ In the future, this section will be populated dynamically. If you are wondering
 Adding a New Category
 ---------------------
 
-It's very easy to add a new category if needed, and you can do so by modifying the `PerfParser categories attribute here <https://searchfox.org/firefox-main/source/tools/tryselect/selectors/perf.py#179>`_. The following is an example of a complex category that gives a good idea of what you have available::
+It's very easy to add a new category if needed, and you can do so by modifying the :searchfox:`PerfParser categories attribute here <tools/tryselect/selectors/perf.py#179>`. The following is an example of a complex category that gives a good idea of what you have available::
 
      "Resource Usage": {
          "query": {
diff --git a/testing/performance/telemetry-alerting/perfdocs/index.rst b/testing/performance/telemetry-alerting/perfdocs/index.rst
index 59ae6ccd2bf9..0407644ed7d3 100644
--- a/testing/performance/telemetry-alerting/perfdocs/index.rst
+++ b/testing/performance/telemetry-alerting/perfdocs/index.rst
@@ -19,7 +19,7 @@ Probe Setup
 .. note::
   Only Windows is currently available for platforms that can be alerted on due to a high number of false positives on Linux, and Mac. Follow `this bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1998552>`_ for progress on this issue. Android is disabled due to other issues and will be looked at `here <https://bugzilla.mozilla.org/show_bug.cgi?id=1976760>`_. Only **timing_distribution** probes are supported with the existing change detection technique.
 
-To enable alerting or monitoring on a telemetry probe, the ``monitor`` field will need to be added to the ``metadata`` section of the probe definition. **This will only work for timing_distribution probes, other probe types are not supported.** `See this probe for an example <https://searchfox.org/mozilla-central/rev/38e462fe13ea42ae6cc391fb36e8b9e82e842b00/netwerk/metrics.yaml#1883-1888>`_. The following provides all possible fields that will be accepted in the ``monitor`` field:
+To enable alerting or monitoring on a telemetry probe, the ``monitor`` field will need to be added to the ``metadata`` section of the probe definition. **This will only work for timing_distribution probes, other probe types are not supported.** :searchfox:`See this probe for an example <mozilla-central/rev/38e462fe13ea42ae6cc391fb36e8b9e82e842b00:netwerk/metrics.yaml#1883-1888>`. The following provides all possible fields that will be accepted in the ``monitor`` field:
 
 .. code-block:: none
 
diff --git a/testing/raptor/raptor/perfdocs/browsertime.rst b/testing/raptor/raptor/perfdocs/browsertime.rst
index e2ff0191a260..0f2900d70294 100644
--- a/testing/raptor/raptor/perfdocs/browsertime.rst
+++ b/testing/raptor/raptor/perfdocs/browsertime.rst
@@ -11,7 +11,7 @@ Browsertime is a harness for running performance tests, similar to Mozilla's Rap
 Source code:
 
 - Our current Browsertime version uses the canonical repo.
-- In-tree: https://searchfox.org/firefox-main/source/tools/browsertime and https://searchfox.org/firefox-main/source/taskcluster/scripts/misc/browsertime.sh
+- In-tree: :searchfox:`tools/browsertime` and :searchfox:`taskcluster/scripts/misc/browsertime.sh`
 
 Running Locally
 ---------------
@@ -188,22 +188,19 @@ Similarly for running tp6m (equivalent to tp6 but for mobile) on Firefox for And
    ./mach try perf --full -q "'tp6m 'webextensions"
 
 The set of extensions installed are the ones listed in the ``"addons"`` property of the condprof customization file
-`webext.json`_ from the ``testing/condprofile/condprof/customization/`` directory.
+:searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` from the ``testing/condprofile/condprof/customization/`` directory.
 
 All extensions listed in the ``webext.json`` file are expected to have been predownloaded and included in the ``firefox-addons.tar`` archive
-defined in the CI fetch config named `firefox-addons`_, but they will be automatically downloaded from the url specified in the ``webext.json``
+defined in the CI fetch config named :searchfox:`firefox-addons <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:taskcluster/ci/fetch/browsertime.yml#169-176>`, but they will be automatically downloaded from the url specified in the ``webext.json``
 file if they are not.
 
 In a try push we allow to run jobs on new extension XPI files not part of the firefox-addons.tar archive, the new extension needs to be just
-added in the `webext.json`_ condprof customization file in a patch part of the same stack of patches being pushed to try.
+added in the :searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` condprof customization file in a patch part of the same stack of patches being pushed to try.
 
-On the contrary new extensions added to the `webext.json`_ condprof customization file on mozilla-central patches will require the XPI file to be
-added to the ``firefox-addons.tar`` archive and the `firefox-addons`_ CI fetch config updated accordingly (missing to update the archive will
+On the contrary new extensions added to the :searchfox:`webext.json <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:testing/condprofile/condprof/customization/webext.json>` condprof customization file on mozilla-central patches will require the XPI file to be
+added to the ``firefox-addons.tar`` archive and the :searchfox:`firefox-addons <mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0:taskcluster/ci/fetch/browsertime.yml#169-176>` CI fetch config updated accordingly (missing to update the archive will
 trigger explicit linter errors, :doc:`see condprof-addons linter docs </code-quality/lint/linters/condprof-addons>`).
 
-.. _webext.json: https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/testing/condprofile/condprof/customization/webext.json
-.. _firefox-addons: https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/taskcluster/ci/fetch/browsertime.yml#169-176
-
 TP6-Bench Test
 --------------
 
@@ -237,9 +234,9 @@ There are multiple ways of adding additional arguments to Browsertime from Rapto
 
 Other methods for adding additional arguments are:
 
-* Define additional arguments in `testing/raptor/raptor/browsertime/base.py <https://searchfox.org/firefox-main/source/testing/raptor/raptor/browsertime/base.py#220-252>`_.
+* Define additional arguments in :searchfox:`testing/raptor/raptor/browsertime/base.py <testing/raptor/raptor/browsertime/base.py#220-252>`.
 
-* Add a ``browsertime_args`` entry to the appropriate manifest with the desired arguments, i.e. `browsertime-tp6.ini <https://searchfox.org/firefox-main/source/testing/raptor/raptor/tests/tp6/desktop/browsertime-tp6.ini>`_ for desktop page load tests. `Example of browsertime_args format <https://searchfox.org/firefox-main/source/testing/raptor/raptor/tests/custom/browsertime-process-switch.ini#27>`_.
+* Add a ``browsertime_args`` entry to the appropriate manifest with the desired arguments, i.e. :searchfox:`browsertime-tp6.ini <testing/raptor/raptor/tests/tp6/desktop/browsertime-tp6.ini>` for desktop page load tests. :searchfox:`Example of browsertime_args format <testing/raptor/raptor/tests/custom/browsertime-process-switch.ini#27>`.
 
 Running Browsertime on Try
 --------------------------
@@ -286,15 +283,15 @@ Equivalent functionality to the ``--gecko-profile`` flag, i.e. something like ``
 Custom profiling with Raptor-Browsertime
 ----------------------------------------
 
-With browsertime you can now use the exposed start/stop commands of the gecko profiler **and** chrome trace. First, one needs to define the ``expose_browser_profiler`` and ``apps`` variables appropriately in the `test's configuration file <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#9,12>`_
+With browsertime you can now use the exposed start/stop commands of the gecko profiler **and** chrome trace. First, one needs to define the ``expose_browser_profiler`` and ``apps`` variables appropriately in the :searchfox:`test's configuration file <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#9,12>`
 
-If you want to run the test in CI then you will want to ensure you set the ``--extra-profiler-run`` flag in the mozharness extra options for where your test is defined in the `browsertime-desktop yaml file <https://searchfox.org/mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7/taskcluster/ci/test/browsertime-desktop.yml#404-406>`_. Otherwise you can just pass the ``--extra-profiler-run`` flag locally in your command line.
+If you want to run the test in CI then you will want to ensure you set the ``--extra-profiler-run`` flag in the mozharness extra options for where your test is defined in the :searchfox:`browsertime-desktop yaml file <mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7:taskcluster/ci/test/browsertime-desktop.yml#404-406>`. Otherwise you can just pass the ``--extra-profiler-run`` flag locally in your command line.
 
-Both of these steps are required to satisfy the ``_expose_browser_profiler()`` `method <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#241>`_ so that the option, `expose_profiler <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#383-386>`_, is passed into your browsertime script. Finally, it should be as simple as calling the ``start()`` & ``stop()`` commands in your `script <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/browsertime/speedometer3.js#14,30-37,58-65>`_.
+Both of these steps are required to satisfy the ``_expose_browser_profiler()`` :searchfox:`method <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#241>` so that the option, :searchfox:`expose_profiler <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#383-386>`, is passed into your browsertime script. Finally, it should be as simple as calling the ``start()`` & ``stop()`` commands in your :searchfox:`script <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/browsertime/speedometer3.js#14,30-37,58-65>`.
 
-For the gecko profiler, you should also keep in mind these `default parameters <https://searchfox.org/mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7/testing/raptor/raptor/browsertime/base.py#474-495>`_, which you may or may not want to change yourself in your tests configuration file.
+For the gecko profiler, you should also keep in mind these :searchfox:`default parameters <mozilla-central/rev/2e06f92ba068e32a9a7213ee726e8171f91605c7:testing/raptor/raptor/browsertime/base.py#474-495>`, which you may or may not want to change yourself in your tests configuration file.
 
-Likewise, for chrome trace you will want to be aware of `these defaults. <https://searchfox.org/mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6/testing/raptor/raptor/browsertime/base.py#646-658>`_
+Likewise, for chrome trace you will want to be aware of :searchfox:`these defaults. <mozilla-central/rev/11d085b63cf74b35737d9c036be80434883dd3f6:testing/raptor/raptor/browsertime/base.py#646-658>`
 
 Upgrading Browsertime In-Tree
 -----------------------------
@@ -314,7 +311,7 @@ Updating Benchmark Tests
 
 To upgrade any of our benchmark tests, you will need to change the revision used in the test manifest. There are three fields that you have available to use there: ``repository_revision`` to denote the revision, ``repository_branch`` to denote the branch name, and ``repository`` to provide the link of the Github repo that contains the benchmark.
 
-For instance, with Speedometer 3 (sp3), we can update the revision `by changing the repository_revision field found here <https://searchfox.org/mozilla-central/rev/aa3ccd258b64abfd4c5ce56c1f512bc7f65b844c/testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#29>`_. If the change isn't found on the default branch (master/main branch), then you will need to add an entry for ``repository_branch`` to specify this.
+For instance, with Speedometer 3 (sp3), we can update the revision :searchfox:`by changing the repository_revision field found here <mozilla-central/rev/aa3ccd258b64abfd4c5ce56c1f512bc7f65b844c:testing/raptor/raptor/tests/benchmarks/speedometer-desktop.ini#29>`. If the change isn't found on the default branch (master/main branch), then you will need to add an entry for ``repository_branch`` to specify this.
 
 If the path to the test file changes (the file that is invoked to run the test), then the ``test_url`` will need to be changed.
 
diff --git a/testing/raptor/raptor/perfdocs/contributing.rst b/testing/raptor/raptor/perfdocs/contributing.rst
index 0d4df613aa3d..3e2c4f3df0f3 100644
--- a/testing/raptor/raptor/perfdocs/contributing.rst
+++ b/testing/raptor/raptor/perfdocs/contributing.rst
@@ -12,7 +12,7 @@ For mobile projects, Raptor tests are on the following repositories:
 
 **Fenix**:
 
-- Repository: `Mozilla Central <https://searchfox.org/firefox-main/source/mobile/android/fenix>`__
+- Repository: :searchfox:`Mozilla Central <mobile/android/fenix>`
 - Tests results: `Treeherder view <https://treeherder.mozilla.org/#/jobs?repo=fenix>`__
 - Schedule: Every 24 hours `Taskcluster force hook <https://tools.taskcluster.net/hooks/project-releng/cron-task-mozilla-mobile-fenix%2Fraptor>`_
 
diff --git a/testing/raptor/raptor/perfdocs/debugging.rst b/testing/raptor/raptor/perfdocs/debugging.rst
index b4fbdfa814da..808d7c331729 100644
--- a/testing/raptor/raptor/perfdocs/debugging.rst
+++ b/testing/raptor/raptor/perfdocs/debugging.rst
@@ -14,9 +14,9 @@ As of now, there is no easy way to do this. Raptor was not built for debugging f
 To debug a functional failure in Raptor you can follow these steps:
 
 #. If bug 1653617 has not landed yet, apply the patch.
-#. Add the --verbose flag to the extra-options list `here <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/raptor.yml#98-101>`__.
-#. If the --setenv doesn't exist yet (`bug 1494669 <https://bugzilla.mozilla.org/show_bug.cgi?id=1494669>`_), then add your MOZ_LOG environment variables to enable additional logging `here <https://searchfox.org/firefox-main/source/testing/raptor/raptor/webextension/desktop.py#42>`_.
-#. If the flag does exist, then you can add the MOZ_LOG variables to the `raptor.yml <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/raptor.yml>`_ configuration file.
+#. Add the --verbose flag to the extra-options list :searchfox:`here <taskcluster/kinds/test/raptor.yml#98-101>`.
+#. If the --setenv doesn't exist yet (`bug 1494669 <https://bugzilla.mozilla.org/show_bug.cgi?id=1494669>`_), then add your MOZ_LOG environment variables to enable additional logging :searchfox:`here <testing/raptor/raptor/webextension/desktop.py#42>`.
+#. If the flag does exist, then you can add the MOZ_LOG variables to the :searchfox:`raptor.yml <taskcluster/kinds/test/raptor.yml>` configuration file.
 #. Push to try if you cannot reproduce the failure locally.
 
 You can follow `bug 1655554 <https://bugzilla.mozilla.org/show_bug.cgi?id=1655554>`_ as we work on improving this workflow.
@@ -26,7 +26,7 @@ In some cases, you might not be able to get logging for what you are debugging (
 Debugging the Raptor Web Extension
 **********************************
 
-When developing on Raptor and debugging, there's often a need to look at the output coming from the `Raptor Web Extension <https://searchfox.org/firefox-main/source/testing/raptor/webext/raptor>`_. Here are some pointers to help.
+When developing on Raptor and debugging, there's often a need to look at the output coming from the :searchfox:`Raptor Web Extension <testing/raptor/webext/raptor>`. Here are some pointers to help.
 
 Raptor Debug Mode
 -----------------
@@ -54,7 +54,7 @@ Running Raptor with debug mode will:
 Manual Debugging on Firefox Desktop
 -----------------------------------
 
-The main Raptor runner is '`runner.js <https://searchfox.org/firefox-main/source/testing/raptor/webext/raptor/runner.js>`_' which is inside the web extension. The code that actually captures the performance measures is in the web extension content code '`measure.js <https://searchfox.org/firefox-main/source/testing/raptor/webext/raptor/measure.js>`_'.
+The main Raptor runner is ':searchfox:`runner.js <testing/raptor/webext/raptor/runner.js>`' which is inside the web extension. The code that actually captures the performance measures is in the web extension content code ':searchfox:`measure.js <testing/raptor/webext/raptor/measure.js>`'.
 
 In order to retrieve the console.log() output from the Raptor runner, do the following:
 
@@ -71,10 +71,10 @@ To retrieve the console.log() output from the Raptor content 'measure.js' code:
 
 Raptor automatically closes the test tab and the entire browser after test completion; which will close any open debug consoles. In order to have more time to review the console logs, Raptor can be temporarily hacked locally in order to prevent the test tab and browser from being closed. Currently this must be done manually, as follows:
 
-#. In the Raptor web extension runner, comment out the line that closes the test tab in the test clean-up. That line of `code is here <https://searchfox.org/mozilla-central/rev/3c85ea2f8700ab17e38b82d77cd44644b4dae703/testing/raptor/webext/raptor/runner.js#357>`_.
-#. Add a return statement at the top of the Raptor control server method that shuts-down the browser, the browser shutdown `method is here <https://searchfox.org/mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128/testing/raptor/raptor/control_server.py#120>`_.
+#. In the Raptor web extension runner, comment out the line that closes the test tab in the test clean-up. That line of :searchfox:`code is here <mozilla-central/rev/3c85ea2f8700ab17e38b82d77cd44644b4dae703:testing/raptor/webext/raptor/runner.js#357>`.
+#. Add a return statement at the top of the Raptor control server method that shuts-down the browser, the browser shutdown :searchfox:`method is here <mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128:testing/raptor/raptor/control_server.py#120>`.
 
-For **benchmark type tests** (i.e. speedometer, motionmark, etc.) Raptor doesn't inject 'measure.js' into the test page content; instead it injects '`benchmark-relay.js <https://searchfox.org/firefox-main/source/testing/raptor/webext/raptor/benchmark-relay.js>`_' into the benchmark test content. Benchmark-relay is as it sounds; it basically relays the test results coming from the benchmark test, to the Raptor web extension runner. Viewing the console.log() output from benchmark-relay is done the same was as noted for the 'measure.js' content above.
+For **benchmark type tests** (i.e. speedometer, motionmark, etc.) Raptor doesn't inject 'measure.js' into the test page content; instead it injects ':searchfox:`benchmark-relay.js <testing/raptor/webext/raptor/benchmark-relay.js>`' into the benchmark test content. Benchmark-relay is as it sounds; it basically relays the test results coming from the benchmark test, to the Raptor web extension runner. Viewing the console.log() output from benchmark-relay is done the same was as noted for the 'measure.js' content above.
 
 Note, `Bug 1470450 <https://bugzilla.mozilla.org/show_bug.cgi?id=1470450>`_ is on file to add a debug mode to Raptor that will automatically grab the web extension console output and dump it to the terminal (if possible) that will make debugging much easier.
 
diff --git a/testing/raptor/raptor/perfdocs/index.rst b/testing/raptor/raptor/perfdocs/index.rst
index 3897898c9ec0..ade50f4e9531 100644
--- a/testing/raptor/raptor/perfdocs/index.rst
+++ b/testing/raptor/raptor/perfdocs/index.rst
@@ -5,7 +5,7 @@ Raptor
 Raptor is a performance-testing framework for running browser pageload and browser benchmark tests. Raptor is cross-browser compatible and is currently running in production on Firefox Desktop, Firefox Android GeckoView, Fenix, Reference Browser, Chromium, Chrome, Chrome for Android, Safari, and Safari Technology Preview.
 
 - Contact: Dave Hunt [:davehunt]
-- Source code: https://searchfox.org/firefox-main/source/testing/raptor
+- Source code: :searchfox:`testing/raptor`
 - Good first bugs: https://codetribute.mozilla.org/projects/automation?project%3DRaptor
 
 Raptor currently supports three test types: 1) page-load performance tests, 2) standard benchmark-performance tests, and 3) "scenario"-based tests, such as power, CPU, and memory-usage measurements on Android and Desktop.
diff --git a/testing/raptor/raptor/perfdocs/test-list.rst b/testing/raptor/raptor/perfdocs/test-list.rst
index c165d9731f66..b1ad920fdba6 100644
--- a/testing/raptor/raptor/perfdocs/test-list.rst
+++ b/testing/raptor/raptor/perfdocs/test-list.rst
@@ -27,8 +27,8 @@ speedometer2
 * data: there are 16 subtests in Speedometer; each of these are made up of 9 internal benchmarks.
 * summarization:
 
-    * subtest: For all of the 16 subtests, we collect `a summed of all their internal benchmark results <https://searchfox.org/firefox-main/source/third_party/webkit/PerformanceTests/Speedometer/resources/benchmark-report.js#66-67>`_ for each of them. To obtain a single score per subtest, we take `a median of the replicates <https://searchfox.org/firefox-main/source/testing/raptor/raptor/output.py#427-470>`_.
-    * score: `geometric mean of the 16 subtest metrics (along with some special corrections) <https://searchfox.org/firefox-main/source/testing/raptor/raptor/output.py#317-330>`_.
+    * subtest: For all of the 16 subtests, we collect :searchfox:`a summed of all their internal benchmark results <third_party/webkit/PerformanceTests/Speedometer/resources/benchmark-report.js#66-67>` for each of them. To obtain a single score per subtest, we take :searchfox:`a median of the replicates <testing/raptor/raptor/output.py#427-470>`.
+    * score: :searchfox:`geometric mean of the 16 subtest metrics (along with some special corrections) <testing/raptor/raptor/output.py#317-330>`.
 
 This is the `Speedometer v1.0 <http://browserbench.org/Speedometer/>`_ JavaScript benchmark taken verbatim and slightly modified to work with the Raptor harness.
 
diff --git a/testing/raptor/raptor/perfdocs/webextension.rst b/testing/raptor/raptor/perfdocs/webextension.rst
index 9da199944bbb..61d83f668603 100644
--- a/testing/raptor/raptor/perfdocs/webextension.rst
+++ b/testing/raptor/raptor/perfdocs/webextension.rst
@@ -13,7 +13,7 @@ WebExtension Page-Load Tests
 
 Page-load tests involve loading a specific web page and measuring the load performance (i.e. `time-to-first-non-blank-paint <https://wiki.mozilla.org/TestEngineering/Performance/Glossary#First_Non-Blank_Paint_.28fnbpaint.29>`_, first-contentful-paint, `dom-content-flushed <https://wiki.mozilla.org/TestEngineering/Performance/Glossary#DOM_Content_Flushed_.28dcf.29>`_).
 
-For page-load tests by default, instead of using live web pages for performance testing, Raptor uses a tool called `Mitmproxy <https://wiki.mozilla.org/TestEngineering/Performance/Raptor/Mitmproxy>`_. Mitmproxy allows us to record and playback test pages via a local Firefox proxy. The Mitmproxy recordings are stored on `tooltool <https://github.com/mozilla/build-tooltool>`_ and are automatically downloaded by Raptor when they are required for a test. Raptor uses mitmproxy via the `mozproxy <https://searchfox.org/firefox-main/source/testing/mozbase/mozproxy>`_ package.
+For page-load tests by default, instead of using live web pages for performance testing, Raptor uses a tool called `Mitmproxy <https://wiki.mozilla.org/TestEngineering/Performance/Raptor/Mitmproxy>`_. Mitmproxy allows us to record and playback test pages via a local Firefox proxy. The Mitmproxy recordings are stored on `tooltool <https://github.com/mozilla/build-tooltool>`_ and are automatically downloaded by Raptor when they are required for a test. Raptor uses mitmproxy via the :searchfox:`mozproxy <testing/mozbase/mozproxy>` package.
 
 There are two different types of Raptor page-load tests: warm page-load and cold page-load.
 
@@ -76,9 +76,9 @@ It is possible to use live web pages for the page-load tests instead of using th
 
 Disabling Alerts
 ================
-It is possible to disable alerting for all our performance tests. Open the target test manifest such as the raptor-tp6*.ini file (`Raptor tests folder <https://searchfox.org/firefox-main/source/testing/raptor/raptor/tests>`_), and make sure there are no ``alert_on`` specifications.
+It is possible to disable alerting for all our performance tests. Open the target test manifest such as the raptor-tp6*.ini file (:searchfox:`Raptor tests folder <testing/raptor/raptor/tests>`), and make sure there are no ``alert_on`` specifications.
 
-When it's removed there will no longer be a ``shouldAlert`` field in the output Perfherder data (you can find the `schema here <https://searchfox.org/firefox-main/source/testing/mozharness/external_tools/performance-artifact-schema.json#68,165>`_). As long as ``shouldAlert`` is not in the data, no alerts will be generated. If you need to also disable code sheriffing for the test, then you need to change the tier of the task to 3.
+When it's removed there will no longer be a ``shouldAlert`` field in the output Perfherder data (you can find the :searchfox:`schema here <testing/mozharness/external_tools/performance-artifact-schema.json#68,165>`). As long as ``shouldAlert`` is not in the data, no alerts will be generated. If you need to also disable code sheriffing for the test, then you need to change the tier of the task to 3.
 
 High value tests
 ================
@@ -389,7 +389,7 @@ You can override the default page-cycles by using the --page-cycles command-line
 
 Running Page-Load Tests on Live Sites
 =====================================
-To use live pages instead of page recordings, just edit the `Raptor tp6* test INI <https://searchfox.org/firefox-main/source/testing/raptor/raptor/tests>`_ file and add the following attribute either at the top (for all pages in the suite) or under an individual page/subtest heading:
+To use live pages instead of page recordings, just edit the :searchfox:`Raptor tp6* test INI <testing/raptor/raptor/tests>` file and add the following attribute either at the top (for all pages in the suite) or under an individual page/subtest heading:
 
   use_live_pages = true
 
@@ -522,4 +522,4 @@ Device specific:
 * gpu governor
 * gpu minimum frequency
 
-For a detailed list of current tweaks, please refer to `this <https://searchfox.org/firefox-main/source/testing/raptor/raptor/raptor.py#676>`_ Searchfox page.
+For a detailed list of current tweaks, please refer to :searchfox:`this <testing/raptor/raptor/raptor.py#676>` Searchfox page.
diff --git a/testing/talos/perfdocs/index.rst b/testing/talos/perfdocs/index.rst
index a306a7906e7f..862f24375ff5 100644
--- a/testing/talos/perfdocs/index.rst
+++ b/testing/talos/perfdocs/index.rst
@@ -13,10 +13,10 @@ named after the `bronze automaton from Greek myth <https://en.wikipedia.org/wiki
    :local:
 
 Talos tests are run in a similar manner to xpcshell and mochitests. They are started via
-the command :code:`mach talos-test`. A `python script <https://searchfox.org/firefox-main/source/testing/talos>`_
+the command :code:`mach talos-test`. A :searchfox:`python script <testing/talos>`
 then launches Firefox, which runs the tests via JavaScript special powers. The test timing
 information is recorded in a text log file, e.g. :code:`browser_output.txt`, and then processed
-into the `JSON format supported by Perfherder <https://searchfox.org/firefox-main/source/testing/mozharness/external_tools/performance-artifact-schema.json>`_.
+into the :searchfox:`JSON format supported by Perfherder <testing/mozharness/external_tools/performance-artifact-schema.json>`.
 
 Talos bugs can be filed in `Testing::Talos <https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=Talos>`_.
 
@@ -123,23 +123,22 @@ At a glance
 ***********
 
 -  Tests are defined in
-   `testing/talos/talos/test.py <https://searchfox.org/firefox-main/source/testing/talos/talos/test.py>`__
+   :searchfox:`testing/talos/talos/test.py`
 -  Treeherder abbreviations are defined in
-   `taskcluster/kinds/test/talos.yml <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/talos.yml>`__
+   :searchfox:`taskcluster/kinds/test/talos.yml`
 -  Suites are defined for production in
-   `testing/talos/talos.json <https://searchfox.org/firefox-main/source/testing/talos/talos.json>`__
+   :searchfox:`testing/talos/talos.json`
 
 Test lifecycle
 **************
 
--  Taskcluster schedules `talos
-   jobs <https://searchfox.org/firefox-main/source/taskcluster/kinds/test/talos.yml>`__
+-  Taskcluster schedules :searchfox:`talos jobs <taskcluster/kinds/test/talos.yml>`
 -  Taskcluster runs a Talos job on a hardware machine when one is
    available - this is bootstrapped by
-   `mozharness <https://searchfox.org/firefox-main/source/testing/mozharness/mozharness/mozilla/testing/talos.py>`__
+   :searchfox:`mozharness <testing/mozharness/mozharness/mozilla/testing/talos.py>`
 
    -  mozharness downloads the build, talos.zip (found in
-      `talos.json <https://searchfox.org/firefox-main/source/testing/talos/talos.json>`__),
+      :searchfox:`talos.json <testing/talos/talos.json>`),
       and creates a virtualenv for running the test.
    -  mozharness `configures the test and runs
       it <https://wiki.mozilla.org/TestEngineering/Performance/Talos/Running#How_Talos_is_Run_in_Production>`__
diff --git a/toolkit/components/autocomplete/docs/index.rst b/toolkit/components/autocomplete/docs/index.rst
index 40eca36578b9..92a7a88aa529 100644
--- a/toolkit/components/autocomplete/docs/index.rst
+++ b/toolkit/components/autocomplete/docs/index.rst
@@ -12,11 +12,11 @@ You might also be interested in learning more about :doc:`address and credit car
 Autocomplete Types in the Browser UI
 ------------------------------------
 
-There are several autocomplete usages in the browser UI, for example, the autcomplete in the search field that can be optionally added to the main toolbar. If a text field in the browser UI wishes to participate in autocomplete, it needs to be based off of the ``autocomplete-input`` type defined in `autocomplete-input.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-input.js>`_. This will handle opening the popup based on various key events in a consistent way across autocomplete fields. Some of this work is performed by a separate `nsAutocompleteController <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsAutoCompleteController.cpp>`_ object which is shared between browser UI and web page autocomplete.
+There are several autocomplete usages in the browser UI, for example, the autcomplete in the search field that can be optionally added to the main toolbar. If a text field in the browser UI wishes to participate in autocomplete, it needs to be based off of the ``autocomplete-input`` type defined in :searchfox:`autocomplete-input.js <toolkit/content/widgets/autocomplete-input.js>`. This will handle opening the popup based on various key events in a consistent way across autocomplete fields. Some of this work is performed by a separate :searchfox:`nsAutocompleteController <toolkit/components/autocomplete/nsAutoCompleteController.cpp>` object which is shared between browser UI and web page autocomplete.
 
 Each type of autocomplete has a search component that is used to perform the actual search for results. Autocomplete search components have the contract id of the form ``@mozilla.org/autocomplete/search;1?name=AAA`` where ``AAA`` is a search type. The search type can be specified by the placing an ``autocompletesearch`` attribute on the text field. For example, assigning a value ``search-autocomplete`` will create the component ``@mozilla.org/autocomplete/search;1?name=search-autocomplete``.
 
-The autocomplete components implement the `nsIAutoCompleteSearch <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>`_ interface which contains a ``startSearch`` function to start a new search given a search term.
+The autocomplete components implement the :searchfox:`nsIAutoCompleteSearch <toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>` interface which contains a ``startSearch`` function to start a new search given a search term.
 
 Multiple search types may be specified in the ``autocompletesearch`` attribute by separating them with spaces.
 
@@ -27,15 +27,15 @@ How Autocomplete is Triggered
 
 For autocomplete in the browser UI, the ``autocomplete-input`` gets the ``nsAutoCompleteController`` object - of which there is only one -- and this manages opening the popup, selecting values from the popup and filling in the input field when an item from the popup is selected.
 
-For autocomplete in web pages, there is a separate form controller object. This form controller is implemeted in `nsFormFillController.cpp <https://searchfox.org/firefox-main/source/toolkit/components/satchel/nsFormFillController.cpp>`_ and is the starting point where it is decided whether autocomplete and form fill apply to a particular form field. This component is loaded at application startup, and there is one of these form fill controllers per child process. This component is intended to be the equivalent to ``autocomplete-input`` for use in web pages, and is used because the real input field cannot be accessed from both the content and browser processes.
+For autocomplete in web pages, there is a separate form controller object. This form controller is implemeted in :searchfox:`nsFormFillController.cpp <toolkit/components/satchel/nsFormFillController.cpp>` and is the starting point where it is decided whether autocomplete and form fill apply to a particular form field. This component is loaded at application startup, and there is one of these form fill controllers per child process. This component is intended to be the equivalent to ``autocomplete-input`` for use in web pages, and is used because the real input field cannot be accessed from both the content and browser processes.
 
 It is this form controller which conforms to the ``nsIAutoCompleteSearch`` interface and is implemented using the ``@mozilla.org/autocomplete/search;1?name=form-fill-controller`` component as described above. In this way, it operates similar to autocomplete in the browser UI using shared code.
 
 The form controller listens for windows to be created by listening for the ``chrome-event-target-created`` observer notification. When a new page is loaded, it adds some event listeners (focus events, key events, mouse events) to the page which will be used to determine whether an autocomplete popop should be displayed in different circumstances.
 
-In most circumstances, an autocomplete action begins when typing into an input field, or, by pressing the cursor or tab keys. For browser UI, this happens in event listeners within the ``autocomplete-input`` implementation. For web pages, this happens in the event listeners added within the `nsFormFillController <https://searchfox.org/firefox-main/source/toolkit/components/satchel/nsFormFillController.cpp>`_. An autocomplete popup can also trigger when clicking the mouse in a field.
+In most circumstances, an autocomplete action begins when typing into an input field, or, by pressing the cursor or tab keys. For browser UI, this happens in event listeners within the ``autocomplete-input`` implementation. For web pages, this happens in the event listeners added within the :searchfox:`nsFormFillController <toolkit/components/satchel/nsFormFillController.cpp>`. An autocomplete popup can also trigger when clicking the mouse in a field.
 
-A special case occurs for password fields as the autocomplete popup can be opened when the input field is focused without having to type into the field. This is done in the handling for the focus event in `nsFormFillController.cpp <https://searchfox.org/firefox-main/source/toolkit/components/satchel/nsFormFillController.cpp>`_. This is where changes would be made to determine whether a popup should be opened on different events. However, at this point, it has not been determined which type of autocomplete search is to be used, so any changes would be general to all autocomplete types. This is probably a good thing, so that the autocomplete behaviour is consistent across all types.
+A special case occurs for password fields as the autocomplete popup can be opened when the input field is focused without having to type into the field. This is done in the handling for the focus event in :searchfox:`nsFormFillController.cpp <toolkit/components/satchel/nsFormFillController.cpp>`. This is where changes would be made to determine whether a popup should be opened on different events. However, at this point, it has not been determined which type of autocomplete search is to be used, so any changes would be general to all autocomplete types. This is probably a good thing, so that the autocomplete behaviour is consistent across all types.
 
 When a suitable key or mouse  event occurs which should trigger a possible autocomplete, the form controller passes this on to ``nsAutoCompleteController``.
 
@@ -47,27 +47,27 @@ Note that both ``nsFormFillController`` and ``nsAutoCompleteController`` operate
 
   Some interfaces you might see being used within the formfill and autocomplete controllers and actors:
 
-  `nsIAutoCompleteInput <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompleteInput.idl>`_
+  :searchfox:`nsIAutoCompleteInput <toolkit/components/autocomplete/nsIAutoCompleteInput.idl>`
     This is an abstraction around the input field that autocomplete might apply to. For browser UI, this is implemented directly by ``autocomplete-input``. For form fill in web pages, this is implemented by the ``nsFormFillController``.
 
-  `nsIAutoCompletePopup <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompletePopup.idl>`_
-    This is an abstraction around the popup that appears for autocomplete. It is implemented by `autocomplete-popup.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-popup.js>`_ for browser UI and supports displaying a number of different types of autocomplete rows. For form fill in web pages, it is implemented by the ``AutoCompleteChild`` actor which redirects through the process boundary to the actual popup also implemented by `autocomplete-popup.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-popup.js>`_.
+  :searchfox:`nsIAutoCompletePopup <toolkit/components/autocomplete/nsIAutoCompletePopup.idl>`
+    This is an abstraction around the popup that appears for autocomplete. It is implemented by :searchfox:`autocomplete-popup.js <toolkit/content/widgets/autocomplete-popup.js>` for browser UI and supports displaying a number of different types of autocomplete rows. For form fill in web pages, it is implemented by the ``AutoCompleteChild`` actor which redirects through the process boundary to the actual popup also implemented by :searchfox:`autocomplete-popup.js <toolkit/content/widgets/autocomplete-popup.js>`.
 
-  `nsIAutoCompleteSearch <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>`_
+  :searchfox:`nsIAutoCompleteSearch <toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>`
     This is an interface used to start and stop the search for specific results. Each search type will implement this to perform the search. For web pages, this is also implemented by the nsFormFillController.
 
-  `nsIAutoCompleteResult <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompleteResult.idl>`_
+  :searchfox:`nsIAutoCompleteResult <toolkit/components/autocomplete/nsIAutoCompleteResult.idl>`
     This interface is implemented by search results. For the form controller, these are returned by ``searchResultToAutoCompleteResult``. For other search types, the search is expected to return objects which implement ``nsIAutoCompleteResult`` directly.
 
 Here is an example code flow for a field on a web page:
 
-1. The user focuses an <input> text field. The form controller nsFormFillController looks to see if this is a password field. If not, it does some initialization to be ready for an autocomplete popup that could appear when the field is modified. This is done in `nsFormFillController::MaybeStartControllingInput <https://searchfox.org/firefox-main/source/toolkit/components/satchel/nsFormFillController.cpp>`_. If the field is a password field, the popup can appear directly on focus.
-2. The user types into the field. The form controller calls into the autocomplete `nsAutocompleteController::HandleText <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsAutoCompleteController.cpp>`_ method to determine when and how the popup should appear based on what was entered into the field. Note that the popup may already be visible and the user is continuing to type and further refine the results.
+1. The user focuses an <input> text field. The form controller nsFormFillController looks to see if this is a password field. If not, it does some initialization to be ready for an autocomplete popup that could appear when the field is modified. This is done in :searchfox:`nsFormFillController::MaybeStartControllingInput <toolkit/components/satchel/nsFormFillController.cpp>`. If the field is a password field, the popup can appear directly on focus.
+2. The user types into the field. The form controller calls into the autocomplete :searchfox:`nsAutocompleteController::HandleText <toolkit/components/autocomplete/nsAutoCompleteController.cpp>` method to determine when and how the popup should appear based on what was entered into the field. Note that the popup may already be visible and the user is continuing to type and further refine the results.
 3. The autocomplete controller looks for a search component of the form ``@mozilla.org/autocomplete/search;1?name=AAA`` as described above. For web page form fill, this is back to the nsFormFillController which redirects to the AutoCompleteChild actor.
 4. The AutoCompleteChild actor looks for a provider for the input field. Search providers are described in more detail in the :ref:`section on child actors<childactor>`. The provider is an object which is able to perform a search for autcomplete results and return them.
-5. The search results are supplied to the listener passed to `nsIAutoCompleteSearch::StartSearch <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>`_. This listener is the autocomplete controller ``nsAutocompleteController`` which takes the results and uses them to display an autocomplete popup if needed.
+5. The search results are supplied to the listener passed to :searchfox:`nsIAutoCompleteSearch::StartSearch <toolkit/components/autocomplete/nsIAutoCompleteSearch.idl>`. This listener is the autocomplete controller ``nsAutocompleteController`` which takes the results and uses them to display an autocomplete popup if needed.
 
-To summarize, if you wish to modify the events which cause an autocomplete popup to show, you would need to modify the `autocomplete-input.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-input.js>`_ for browser UI and the `nsFormController <https://searchfox.org/firefox-main/source/toolkit/components/satchel/nsFormFillController.cpp>`_ for web page fields. The `nsAutocompleteController <https://searchfox.org/firefox-main/source/toolkit/components/autocomplete/nsAutoCompleteController.cpp>`_ contains code which is shared between both.
+To summarize, if you wish to modify the events which cause an autocomplete popup to show, you would need to modify the :searchfox:`autocomplete-input.js <toolkit/content/widgets/autocomplete-input.js>` for browser UI and the :searchfox:`nsFormController <toolkit/components/satchel/nsFormFillController.cpp>` for web page fields. The :searchfox:`nsAutocompleteController <toolkit/components/autocomplete/nsAutoCompleteController.cpp>` contains code which is shared between both.
 
 Autocomplete Types in Web Pages (Form Fill)
 -------------------------------------------
@@ -83,22 +83,22 @@ Each of these is implemented by a pair of actors, one in each process.
 There is an actor pair for each of these three types:
 
   ``Login Manager``:
-    * `toolkit/components/passwordmgr/LoginManagerChild.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/passwordmgr/LoginManagerChild.sys.mjs>`_
-    * `toolkit/components/passwordmgr/LoginManagerParent.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/passwordmgr/LoginManagerParent.sys.mjs>`_
+    * :searchfox:`toolkit/components/passwordmgr/LoginManagerChild.sys.mjs`
+    * :searchfox:`toolkit/components/passwordmgr/LoginManagerParent.sys.mjs`
 
   ``Form Autofill``:
-    * `toolkit/components/formautofill/FormAutofillChild.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/FormAutofillChild.sys.mjs>`_
-    * `toolkit/components/formautofill/FormAutofillParent.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/formautofill/FormAutofillParent.sys.mjs>`_
+    * :searchfox:`toolkit/components/formautofill/FormAutofillChild.sys.mjs`
+    * :searchfox:`toolkit/components/formautofill/FormAutofillParent.sys.mjs`
 
   ``Form History``:
-    * `toolkit/components/satchel/FormHistoryChild.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/satchel/FormHistoryChild.sys.mjs>`_
-    * `toolkit/components/satchel/FormHistoryParent.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/satchel/FormHistoryParent.sys.mjs>`_
+    * :searchfox:`toolkit/components/satchel/FormHistoryChild.sys.mjs`
+    * :searchfox:`toolkit/components/satchel/FormHistoryParent.sys.mjs`
 
 There is also a fourth more general actor pair used for the autocomplete system itself:
 
   ``AutoComplete``:
-    * `toolkit/actors/AutoCompleteChild.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/actors/AutoCompleteChild.sys.mjs>`_
-    * `toolkit/actors/AutoCompleteParent.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/actors/AutoCompleteParent.sys.mjs>`_
+    * :searchfox:`toolkit/actors/AutoCompleteChild.sys.mjs`
+    * :searchfox:`toolkit/actors/AutoCompleteParent.sys.mjs`
 
 Since the autocomplete UI widgets for the popup only appear in the browser process, this last set of actors are used to abstract this out so that the autocomplete system can operate as if it was in the same process.
 
@@ -118,7 +118,7 @@ These providers are implemented by the child actor. For example, the form autofi
 However, the other two are actually supplied by default by the ``AutoCompleteChild`` child actor, and are included in addition to any custom providers. If the field is a password field, or has been a password field in the past, the child autocomplete actor adds a default provider to handle logins called "LoginManager", which corresponds to the ``LoginManagerChild`` actor. For form history for all input fields, the "FormHistory" provider is used, corresponding to the ``FormHistoryChild`` actor.
 
 When multiple providers are used, they are currently searched according to a priority, the order of which is
-hard-coded in the ``AUTOCOMPLETE_PROVIDERS`` constant within `toolkit/actors/AutoCompleteParent.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/actors/AutoCompleteParent.sys.mjs>`_.
+hard-coded in the ``AUTOCOMPLETE_PROVIDERS`` constant within :searchfox:`toolkit/actors/AutoCompleteParent.sys.mjs`.
 
 The provider has three important functions defined:
 
@@ -169,7 +169,7 @@ Result Object Fields:
  :comment: a serialized JSON object containing additional properties that might be used by the row
 
 The autocomplete popup supports around 10 or so different styles for rows to appear in, for example: "status" for status rows, and "autofill" for form fill items. Each style uses the label, image and comment in a different way. You can add more styles by adding an implementation to
-`autocomplete-richlistitem.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-richlistitem.js>`_ and then adding a corresponding reference within `autocomplete-popup.js <https://searchfox.org/firefox-main/source/toolkit/content/widgets/autocomplete-popup.js>`_ to match.
+:searchfox:`autocomplete-richlistitem.js <toolkit/content/widgets/autocomplete-richlistitem.js>` and then adding a corresponding reference within :searchfox:`autocomplete-popup.js <toolkit/content/widgets/autocomplete-popup.js>` to match.
 
 By default, the "value" field will be filled into the textbox when the item is selected from the popup. However, if the comment field contains ``fillMessageName`` and ``fillMessageData`` properties, these can be used to send custom messages to the actor which implements the autocomplete. The message name must match the actor, for example a message name ``FormAutofill:SaveAddress`` will map to the FormAutofill actor which was described earlier. This allows custom actions to be performed when selecting items from the autocomplete popup. The actor's ``onAutoCompleteEntrySelected`` function will be used to implement this. This behaviour is used when you need a custom action to be performed when selecting an item. For example, to open a settings panel.
 
diff --git a/toolkit/components/crashes/docs/crash-ping-lifecycle.rst b/toolkit/components/crashes/docs/crash-ping-lifecycle.rst
index fd18a97e92aa..189e0d5b1955 100644
--- a/toolkit/components/crashes/docs/crash-ping-lifecycle.rst
+++ b/toolkit/components/crashes/docs/crash-ping-lifecycle.rst
@@ -18,17 +18,13 @@ Ping Definitions
 ----------------
 * `Desktop crash ping <https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/pings/crash>`_
 
-  * `Desktop metrics definition
-    <https://searchfox.org/firefox-main/source/toolkit/components/crashes/metrics.yaml>`_
-  * `Desktop ping definition
-    <https://searchfox.org/firefox-main/source/toolkit/components/crashes/pings.yaml>`_
+  * :searchfox:`Desktop metrics definition <toolkit/components/crashes/metrics.yaml>`
+  * :searchfox:`Desktop ping definition <toolkit/components/crashes/pings.yaml>`
 
 * `Fenix crash ping <https://dictionary.telemetry.mozilla.org/apps/fenix/pings/crash>`_
 
-  * `Fenix metrics definition
-    <https://searchfox.org/firefox-main/source/mobile/android/android-components/components/lib/crash/metrics.yaml>`_
-  * `Fenix ping definition
-    <https://searchfox.org/firefox-main/source/mobile/android/android-components/components/lib/crash/pings.yaml>`_
+  * :searchfox:`Fenix metrics definition <mobile/android/android-components/components/lib/crash/metrics.yaml>`
+  * :searchfox:`Fenix ping definition <mobile/android/android-components/components/lib/crash/pings.yaml>`
 
 BigQuery Tables
 ---------------
@@ -73,11 +69,11 @@ BigQuery Tables
 
 Source
 ------
-All crash ping metrics are set in bulk at the same time, and typically come directly from `crash annotations <https://searchfox.org/firefox-main/source/toolkit/crashreporter/CrashAnnotations.yaml>`_:
+All crash ping metrics are set in bulk at the same time, and typically come directly from :searchfox:`crash annotations <toolkit/crashreporter/CrashAnnotations.yaml>`:
 
-* `Desktop <https://searchfox.org/mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02/toolkit/components/crashes/CrashManager.in.sys.mjs#787>`__
-* `Crashreporter client <https://searchfox.org/mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02/toolkit/crashreporter/client/app/src/net/ping/glean.rs#11>`__
-* `Fenix <https://searchfox.org/mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02/mobile/android/android-components/components/lib/crash/src/main/java/mozilla/components/lib/crash/service/GleanCrashReporterService.kt#312>`__
+* :searchfox:`Desktop <mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02:toolkit/components/crashes/CrashManager.in.sys.mjs#787>`
+* :searchfox:`Crashreporter client <mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02:toolkit/crashreporter/client/app/src/net/ping/glean.rs#11>`
+* :searchfox:`Fenix <mozilla-central/rev/b598575345077063c55b618e43ccaa6249505d02:mobile/android/android-components/components/lib/crash/src/main/java/mozilla/components/lib/crash/service/GleanCrashReporterService.kt#312>`
 
 
 Post-Processing
@@ -127,8 +123,7 @@ efficient loading in the browser.
 
 Adding data to crash pings
 ==========================
-#. Add crash annotations to the `definition file
-   <https://searchfox.org/firefox-main/source/toolkit/crashreporter/CrashAnnotations.yaml>`_ and
+#. Add crash annotations to the :searchfox:`definition file <toolkit/crashreporter/CrashAnnotations.yaml>` and
    populate the annotations with the generated APIs.
 #. Define corresponding glean metrics to the files listed in `Ping Definitions`_.
 #. Update the code that populates the metrics listed in `Source`_.
diff --git a/toolkit/components/extensions/docs/basics.rst b/toolkit/components/extensions/docs/basics.rst
index 404a91729728..f2bbfaf2bf19 100644
--- a/toolkit/components/extensions/docs/basics.rst
+++ b/toolkit/components/extensions/docs/basics.rst
@@ -243,13 +243,13 @@ all API scripts look to the following source:
 
 - `SchemaAPIManager _createExtGlobal method <https://searchfox.org/mozilla-central/search?q=symbol:SchemaAPIManager%23_createExtGlobal&redirect=false>`_
 - Only available in the parent Firefox process:
-  `toolkit/components/extensions/parent/ext-toolkit.js <https://searchfox.org/firefox-main/source/toolkit/components/extensions/parent/ext-toolkit.js>`_
+  :searchfox:`toolkit/components/extensions/parent/ext-toolkit.js`
 - Only available in the child Firefox process:
-  `toolkit/components/extensions/child/ext-toolkit.js <https://searchfox.org/firefox-main/source/toolkit/components/extensions/child/ext-toolkit.js>`_
+  :searchfox:`toolkit/components/extensions/child/ext-toolkit.js`
 - Only available in the Desktop builds:
-  `browser/components/extensions/parent/ext-browser.js <https://searchfox.org/firefox-main/source/browser/components/extensions/parent/ext-browser.js>`_
+  :searchfox:`browser/components/extensions/parent/ext-browser.js`
 - Only available in the Android builds:
-  `mobile/shared/components/extensions/ext-android.js <https://searchfox.org/firefox-main/source/mobile/shared/components/extensions/ext-android.js>`_
+  :searchfox:`mobile/shared/components/extensions/ext-android.js`
 
 .. warning::
    The extension API authors should never redefine these globals to avoid introducing potential
diff --git a/toolkit/components/extensions/docs/incognito.rst b/toolkit/components/extensions/docs/incognito.rst
index 7df71e77c4fd..27c8fef33131 100644
--- a/toolkit/components/extensions/docs/incognito.rst
+++ b/toolkit/components/extensions/docs/incognito.rst
@@ -52,7 +52,7 @@ extension to run tests against it.
 There are two utility functions in head.js, getIncognitoWindow and
 startIncognitoMonitorExtension, which are useful for some basic testing.
 
-Example: `browser_ext_windows_events.js <https://searchfox.org/mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e/browser/components/extensions/test/browser/browser_ext_windows_events.js>`_
+Example: :searchfox:`browser_ext_windows_events.js <mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e:browser/components/extensions/test/browser/browser_ext_windows_events.js>`
 
 Testing API Calls
 -----------------
@@ -62,7 +62,7 @@ an ID of a window or tab, use getIncognitoWindow.  In most cases, the
 API call should throw an exception when the window is not accessible.
 There are some cases where API calls explicitly do not throw.
 
-Example: `browser_ext_windows_incognito.js <https://searchfox.org/mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e/browser/components/extensions/test/browser/browser_ext_windows_incognito.js>`_
+Example: :searchfox:`browser_ext_windows_incognito.js <mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e:browser/components/extensions/test/browser/browser_ext_windows_incognito.js>`
 
 Privateness of window vs. tab
 -----------------------------
diff --git a/toolkit/components/extensions/docs/other.rst b/toolkit/components/extensions/docs/other.rst
index 85a9b6db41bb..7aa713a6cce1 100644
--- a/toolkit/components/extensions/docs/other.rst
+++ b/toolkit/components/extensions/docs/other.rst
@@ -105,7 +105,7 @@ disabled or uninstalled, the prior user-set or default values would be returned
 
 An extension may watch for changes using the onChange api (e.g. browserSettings.settingName.onChange).
 
-[1] https://searchfox.org/mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006/toolkit/components/extensions/ext-toolkit.json#19
+[1] :searchfox:`mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006:toolkit/components/extensions/ext-toolkit.json#19`
 
 Notifications:
 ^^^^^^^^^^^^^^
diff --git a/toolkit/components/extensions/docs/webext-storage.rst b/toolkit/components/extensions/docs/webext-storage.rst
index 8d1a4823fde1..310bd3133705 100644
--- a/toolkit/components/extensions/docs/webext-storage.rst
+++ b/toolkit/components/extensions/docs/webext-storage.rst
@@ -5,11 +5,11 @@ How webext storage works
 This document describes the implementation of the the `storage.sync` part of the
 `WebExtensions Storage APIs
 <https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/storage>`_.
-The implementation lives in the `toolkit/components/extensions/storage folder <https://searchfox.org/firefox-main/source/toolkit/components/extensions/storage>`_
+The implementation lives in the :searchfox:`toolkit/components/extensions/storage folder <toolkit/components/extensions/storage>`
 
 The app-services component `lives on github <https://github.com/mozilla/application-services/blob/main/components/webext-storage>`_.
 There are docs that describe `how to update/vendor this (and all) external rust code <../../../../build/buildsystem/rust.html>`_ you might be interested in.
-We use UniFFI to generate JS bindings for the components. More details about UniFFI can be found in `these docs <https://searchfox.org/firefox-main/source/docs/writing-rust-code/uniffi.md>`_.
+We use UniFFI to generate JS bindings for the components. More details about UniFFI can be found in `these docs <https://firefox-source-docs.mozilla.org/rust-components/developing-rust-components/uniffi.html>`_.
 
 To set the scene, let's look at the parts exposed to WebExtensions first; there are lots of
 moving part there too.
@@ -19,7 +19,7 @@ WebExtension API
 
 The WebExtension API is owned by the addons team. The implementation of this API is quite complex
 as it involves multiple processes, but for the sake of this document, we can consider the entry-point
-into the WebExtension Storage API as being `parent/ext-storage.js <https://searchfox.org/firefox-main/source/toolkit/components/extensions/parent/ext-storage.js>`_.
+into the WebExtension Storage API as being :searchfox:`parent/ext-storage.js <toolkit/components/extensions/parent/ext-storage.js>`.
 
 Overview of the API
 ###################
diff --git a/toolkit/components/extensions/docs/webidl_bindings.rst b/toolkit/components/extensions/docs/webidl_bindings.rst
index 3558e03480e7..b2a646555745 100644
--- a/toolkit/components/extensions/docs/webidl_bindings.rst
+++ b/toolkit/components/extensions/docs/webidl_bindings.rst
@@ -52,11 +52,8 @@ restricted to the WebExtensions background service worker through the
 ``mozilla::extensions::ExtensionAPIAllowed`` helper function.
 
 See ``ExtensionBrowser`` and ``ExtensionGlobalsMixin`` interfaces defined from
-ExtensionBrowser.webidl_ and ``mozilla::extensions::ExtensionAPIAllowed`` defined in
-ExtensionBrowser.cpp_.
-
-.. _ExtensionBrowser.webidl: https://searchfox.org/firefox-main/source/dom/webidl/ExtensionBrowser.webidl
-.. _ExtensionBrowser.cpp: https://searchfox.org/firefox-main/source/toolkit/components/extensions/webidl-api/ExtensionBrowser.cpp
+:searchfox:`ExtensionBrowser.webidl <dom/webidl/ExtensionBrowser.webidl>` and ``mozilla::extensions::ExtensionAPIAllowed`` defined in
+:searchfox:`ExtensionBrowser.cpp <toolkit/components/extensions/webidl-api/ExtensionBrowser.cpp>`.
 
 Why do all the webidl interfaces for WebExtensions API use LegacyNoInterfaceObject?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/toolkit/components/messaging-system/schemas/index.rst b/toolkit/components/messaging-system/schemas/index.rst
index 084aff9a1813..36269c1b9911 100644
--- a/toolkit/components/messaging-system/schemas/index.rst
+++ b/toolkit/components/messaging-system/schemas/index.rst
@@ -14,18 +14,17 @@ Messages
 There are JSON schemas for each type of message that the Firefox Messaging
 System handles:
 
-* `CFR URLBar Chiclet <cfr_urlbar_chiclet_schema_>`_
-* `Extension Doorhanger <extension_doorhanger_schema_>`_
-* `Infobar <infobar_schema_>`_
-* `Spotlight <spotlight_schema_>`_
-* `Toast Notification <toast_notification_schema_>`_
-* `Toolbar Badge <toolbar_badge_schema_>`_
-* `Update Action <update_action_schema_>`_
-* `Whats New <whats_new_schema_>`_
-* `Private Browsing Newtab Promo Message <pbnewtab_promo_schema_>`_
+* :searchfox:`CFR URLBar Chiclet <browser/components/asrouter/content-src/templates/CFR/templates/CFRUrlbarChiclet.schema.json>`
+* :searchfox:`Extension Doorhanger <browser/components/asrouter/content-src/templates/CFR/templates/ExtensionDoorhanger.schema.json>`
+* :searchfox:`Infobar <browser/components/asrouter/content-src/templates/CFR/templates/InfoBar.schema.json>`
+* :searchfox:`Spotlight <browser/components/asrouter/content-src/templates/OnboardingMessage/Spotlight.schema.json>`
+* :searchfox:`Toast Notification <browser/components/asrouter/content-src/templates/ToastNotification/ToastNotification.schema.json>`
+* :searchfox:`Toolbar Badge <browser/components/asrouter/content-src/templates/OnboardingMessage/ToolbarBadgeMessage.schema.json>`
+* :searchfox:`Update Action <browser/components/asrouter/content-src/templates/OnboardingMessage/UpdateAction.schema.json>`
+* :searchfox:`Whats New <browser/components/asrouter/content-src/templates/OnboardingMessage/WhatsNewMessage.schema.json>`
+* :searchfox:`Private Browsing Newtab Promo Message <browser/components/asrouter/content-src/templates/PBNewtab/NewtabPromoMessage.schema.json>`
 
-Together, they are combined into the `Messaging Experiments
-<messaging_experiments_schema_>`_ via a `script <make_schemas_script_>`_. This
+Together, they are combined into the :searchfox:`Messaging Experiments <browser/components/asrouter/content-src/schemas/MessagingExperiment.schema.json>` via a :searchfox:`script <browser/components/asrouter/content-src/schemas/make-schemas.py>`. This
 is the schema used for Nimbus experiments that target messaging features. All
 incoming messaging experiments will be validated against this schema.
 
@@ -62,7 +61,7 @@ To add a new message type to the Messaging Experiments schema:
    ``{ "$ref": "#!/$defs/Foo" }``) to work in the bundled schema. See docs on
    `bundling JSON schemas <jsonschema_bundling_>`_ for more information.
 
-3. Add the new schema to the list in `make-schemas.py <make_schemas_script_>`_.
+3. Add the new schema to the list in :searchfox:`make-schemas.py <browser/components/asrouter/content-src/schemas/make-schemas.py>`.
 4. Build the new schema by running:
 
    .. code-block:: shell
@@ -80,7 +79,7 @@ schema:
    cd browser/components/asrouter/content-src/schemas/
    ../../../../../mach python make-schemas.py
 
-If you do not, the `Firefox MS Schemas CI job <make_schemas_check_>`_ will fail.
+If you do not, the :searchfox:`Firefox MS Schemas CI job <taskcluster/kinds/source-test/python.yml#425-438>` will fail.
 
 .. _run_make_schemas:
 
@@ -104,7 +103,7 @@ Shared Definitions
 Some definitions are shared across multiple schemas. Instead of copying and
 pasting the definitions between them and then having to manually keep them up to
 date, we keep them in a common schema that contains these defintitions:
-`FxMsCommon.schema.json <common_schema_>`_.  Any definition that will be re-used
+:searchfox:`FxMsCommon.schema.json <browser/components/asrouter/content-src/schemas/FxMSCommon.schema.json>`.  Any definition that will be re-used
 across multiple schemas should be added to the common schema, which will have
 its definitions bundled into the generated schema. All references to the common
 schema will be rewritten in the generated schema.
@@ -136,15 +135,14 @@ An example of using the ``localizableText`` definition in a message schema follo
 Schema Tests
 ------------
 
-We have in-tree tests (`Test_CFRMessageProvider`_,
-`Test_OnboardingMessageProvider`_, and `Test_PanelTestProvider`_), which
+We have in-tree tests (:searchfox:`Test_CFRMessageProvider <browser/components/asrouter/tests//xpcshell/test_CFMessageProvider.js>`,
+:searchfox:`Test_OnboardingMessageProvider <browser/components/asrouter/tests//xpcshell/test_OnboardingMessageProvider.js>`, and :searchfox:`Test_PanelTestProvider <browser/components/asrouter/tests//xpcshell/test_PanelTestProvider.js>`), which
 validate existing messages with the generated schema.
 
 We also have compatibility tests for ensuring that our schemas work in
 `Experimenter`_.  `Experimenter`_ uses a different JSON schema validation
-library, which is reused in the `Firefox MS Schemas CI job
-<make_schemas_check_>`_. This test validates a test corpus from
-`CFRMessageProvider`_, `OnboardingMessageProvider`_, and `PanelTestProvider`_
+library, which is reused in the :searchfox:`Firefox MS Schemas CI job <taskcluster/kinds/source-test/python.yml#425-438>`. This test validates a test corpus from
+:searchfox:`CFRMessageProvider <browser/components/asrouter/modules/CFRMessageProvider.sys.mjs>`, :searchfox:`OnboardingMessageProvider <browser/components/asrouter/modules/OnboardingMessageProvider.sys.mjs>`, and :searchfox:`PanelTestProvider <browser/components/asrouter/modules/PanelTestProvider.sys.mjs>`
 with the same JSON schema validation library and configuration as Experimenter.
 
 See how to run these tests :ref:`above <run_make_schemas>`.
@@ -159,29 +157,7 @@ Triggers and actions
   SpecialMessageActionSchemas/index
   TriggerActionSchemas/index
 
-..  _cfr_urlbar_chiclet_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/CFR/templates/CFRUrlbarChiclet.schema.json
-..  _extension_doorhanger_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/CFR/templates/ExtensionDoorhanger.schema.json
-..  _infobar_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/CFR/templates/InfoBar.schema.json
-..  _spotlight_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/Spotlight.schema.json
-..  _toast_notification_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/ToastNotification/ToastNotification.schema.json
-..  _toolbar_badge_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/ToolbarBadgeMessage.schema.json
-..  _update_action_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/UpdateAction.schema.json
-..  _whats_new_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/WhatsNewMessage.schema.json
-..  _protections_panel_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/ProtectionsPanelMessage.schema.json
-..  _pbnewtab_promo_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/PBNewtab/NewtabPromoMessage.schema.json
-..  _newtab_message_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/templates/OnboardingMessage/NewtabMessage.schema.json
-..  _messaging_experiments_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/schemas/MessagingExperiment.schema.json
-..  _common_schema: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/schemas/FxMSCommon.schema.json
-
-..  _make_schemas_script: https://searchfox.org/firefox-main/source/browser/components/asrouter/content-src/schemas/make-schemas.py
+..  _protections_panel_schema: :searchfox:`browser/components/asrouter/content-src/templates/OnboardingMessage/ProtectionsPanelMessage.schema.json`
+..  _newtab_message_schema: :searchfox:`browser/components/asrouter/content-src/templates/OnboardingMessage/NewtabMessage.schema.json`
 ..  _jsonschema_bundling: https://json-schema.org/understanding-json-schema/structuring.html#bundling
-..  _make_schemas_check: https://searchfox.org/firefox-main/source/taskcluster/kinds/source-test/python.yml#425-438
-
 ..  _Experimenter: https://experimenter.info
-
-..  _CFRMessageProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/modules/CFRMessageProvider.sys.mjs
-..  _PanelTestProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/modules/PanelTestProvider.sys.mjs
-..  _OnboardingMessageProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/modules/OnboardingMessageProvider.sys.mjs
-..  _Test_CFRMessageProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/tests//xpcshell/test_CFMessageProvider.js
-..  _Test_OnboardingMessageProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/tests//xpcshell/test_OnboardingMessageProvider.js
-..  _Test_PanelTestProvider: https://searchfox.org/firefox-main/source/browser/components/asrouter/tests//xpcshell/test_PanelTestProvider.js
diff --git a/toolkit/components/ml/docs/models.rst b/toolkit/components/ml/docs/models.rst
index 0116a4a123ed..e3098211e4d5 100644
--- a/toolkit/components/ml/docs/models.rst
+++ b/toolkit/components/ml/docs/models.rst
@@ -36,7 +36,7 @@ You do not need to rename the encoder models.
 By default, the conversion script above generates a single file containing both the ONNX model architecture and its weights.
 
 To split the model architecture and weights into separate files, you can use the script provided at:
-`convert_to_external_data.py <https://searchfox.org/firefox-main/source/toolkit/components/ml/tools/convert_to_external_data.py>`_.
+:searchfox:`convert_to_external_data.py <toolkit/components/ml/tools/convert_to_external_data.py>`.
 
 This process, known as using the external data format, provides additional speed and memory benefits for your model.
 
@@ -91,7 +91,7 @@ For example, the PDF.js image-to-text record is:
    }
 
 
-If you are adding in Firefox a new inference call, create a new unique `featureId` in `FEATURES <https://searchfox.org/firefox-main/source/toolkit/components/ml/content/EngineProcess.sys.mjs>`_ and add a record in `ml-inference-options` with the task settings.
+If you are adding in Firefox a new inference call, create a new unique `featureId` in :searchfox:`FEATURES <toolkit/components/ml/content/EngineProcess.sys.mjs>` and add a record in `ml-inference-options` with the task settings.
 
 By doing this, you will be able to create an engine with this simple call:
 
diff --git a/toolkit/components/pictureinpicture/docs/index.rst b/toolkit/components/pictureinpicture/docs/index.rst
index 29619267f598..8682e9a95269 100644
--- a/toolkit/components/pictureinpicture/docs/index.rst
+++ b/toolkit/components/pictureinpicture/docs/index.rst
@@ -201,8 +201,8 @@ A site-specific video wrapper allows for the creation of custom scripts that the
 ``PictureInPictureChildVideoWrapper`` and ``videoWrapperScriptPath``
 --------------------------------------------------------------------
 ``PictureInPictureChildVideoWrapper`` is a special class that represents a video wrapper. It is defined in ``PictureInPictureChild.sys.mjs`` and maps to a ``videoWrapperScriptPath``, which is the path of the custom wrapper script to use.
-``videoWrapperScriptPath`` is defined in `browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js <https://searchfox.org/firefox-main/source/browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js>`_ for a domain,
-and custom wrapper scripts are defined in `browser/extensions/pictureinpicture/video-wrappers <https://searchfox.org/firefox-main/source/browser/extensions/pictureinpicture/video-wrappers>`_.
+``videoWrapperScriptPath`` is defined in :searchfox:`browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js` for a domain,
+and custom wrapper scripts are defined in :searchfox:`browser/extensions/pictureinpicture/video-wrappers`.
 
 If a ``videoWrapperScriptPath`` is detected while initializing the Picture-in-Picture toggle or window, we immediately create a new instance of ``PictureInPictureChildVideoWrapper`` based on the given path, allowing us to run our custom scripts.
 
@@ -219,7 +219,7 @@ Adding a new site-specific video wrapper
 ----------------------------------------
 Creating a new wrapper script file
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Add a new JS file for the new video wrapper in `browser/extensions/pictureinpicture/video-wrappers <https://searchfox.org/firefox-main/source/browser/extensions/pictureinpicture/video-wrappers>`_.
+Add a new JS file for the new video wrapper in :searchfox:`browser/extensions/pictureinpicture/video-wrappers`.
 The file must meet several requirements to get the wrapper working.
 
 **Script file requirements**:
@@ -260,7 +260,7 @@ Below is an example of a script file ``mock-wrapper.js`` that overrides an exist
 
 Declaring ``videoWrapperScriptPath``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Declare a property ``videoWrapperScriptPath`` for the site at `browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js <https://searchfox.org/firefox-main/source/browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js>`_:
+Declare a property ``videoWrapperScriptPath`` for the site at :searchfox:`browser/extensions/pictureinpicture/data/picture_in_picture_overrides.js`:
 
 .. code-block:: js
 
@@ -338,7 +338,7 @@ Testing site-specific video wrappers
 ------------------------------------
 Automated Tests
 ^^^^^^^^^^^^^^^
-Automated tests for site specific wrappers are currently limited. New tests can be made in `browser/extensions/pictureinpicture/tests/browser <https://searchfox.org/firefox-main/source/browser/extensions/pictureinpicture/tests/browser>`_ to ensure
+Automated tests for site specific wrappers are currently limited. New tests can be made in :searchfox:`browser/extensions/pictureinpicture/tests/browser` to ensure
 general functionality, but these are restricted to Firefox Nightly and do not test functionality on specific sites.
 
 Some challenges with writing tests include:
diff --git a/toolkit/components/prompts/docs/nsIPromptService-reference.rst b/toolkit/components/prompts/docs/nsIPromptService-reference.rst
index 635ec05ab16e..ebc564e50417 100644
--- a/toolkit/components/prompts/docs/nsIPromptService-reference.rst
+++ b/toolkit/components/prompts/docs/nsIPromptService-reference.rst
@@ -4,7 +4,7 @@ Prompt Service Reference
 
 This is the JSDoc from the Prompter.sys.mjs implementation. You can find the full
 interface definition in
-`nsIPromptService.idl <https://searchfox.org/firefox-main/source/toolkit/components/windowwatcher/nsIPromptService.idl>`_.
+:searchfox:`nsIPromptService.idl <toolkit/components/windowwatcher/nsIPromptService.idl>`.
 
 .. js:autoclass:: Prompter
   :members:
diff --git a/toolkit/components/resistfingerprinting/docs/implementation.rst b/toolkit/components/resistfingerprinting/docs/implementation.rst
index d0f9a924dc29..8f35b09841ff 100644
--- a/toolkit/components/resistfingerprinting/docs/implementation.rst
+++ b/toolkit/components/resistfingerprinting/docs/implementation.rst
@@ -75,4 +75,4 @@ Fingerprinting Resistance takes into account many things to determine if we shou
 
 All callsites for ``ShouldResistFingerprinting`` take a (currently) optional ``RFPTarget`` value, which defaults to ``Unknown``.  While arguments such as ``Document`` or ``nsIChannel`` provide context for the first four exemptions above, the Target provides context for the final one.  A Target is a Web API or an activity - such as a Pointer Event, the Screen Orientation, or plugging a gamepad into your computer (and therefore producing a `gamepadconnected event <https://www.w3.org/TR/gamepad/#event-gamepadconnected>`_).  Most Targets correlate strongly to a specific Web API, but not all do: for example whether or not to automatically reject Canvas extraction requests from third parties is a separate Target from prompting to reject canvas extraction.
 
-In some situations we may *not* alter our behavior for a certain activity - this could be based on the fingerprinting resistance mode you are using, or per-site overrides to correct breakage.  Targets are defined `RFPTargets.inc <https://searchfox.org/firefox-main/source/toolkit/components/resistfingerprinting/RFPTargets.inc>`_.
+In some situations we may *not* alter our behavior for a certain activity - this could be based on the fingerprinting resistance mode you are using, or per-site overrides to correct breakage.  Targets are defined :searchfox:`RFPTargets.inc <toolkit/components/resistfingerprinting/RFPTargets.inc>`.
diff --git a/toolkit/components/search/docs/SearchConfigurationSchema.rst b/toolkit/components/search/docs/SearchConfigurationSchema.rst
index 6725c71cd046..32a132e468eb 100644
--- a/toolkit/components/search/docs/SearchConfigurationSchema.rst
+++ b/toolkit/components/search/docs/SearchConfigurationSchema.rst
@@ -2,9 +2,9 @@
 Search Configuration Schema
 ===========================
 
-This document outlines the details of the `search-config-v2`_ schema and how
+This document outlines the details of the :searchfox:`search-config-v2 <services/settings/dumps/main/search-config-v2.json>` schema and how
 the various sub-parts interact. For the full fields and descriptions, please see
-the `schema itself`_.
+the :searchfox:`schema itself <toolkit/components/search/schema/>`.
 
 .. note::
     In the examples, only relevant properties are displayed.
@@ -385,6 +385,4 @@ configuration, the following algorithm is used by the search engine selector:
 
 #. Otherwise, the locale used doesn't matter, and either form may be used.
 
-.. _schema itself: https://searchfox.org/firefox-main/source/toolkit/components/search/schema/
 .. _the version comparator: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/version/format
-.. _search-config-v2: https://searchfox.org/firefox-main/source/services/settings/dumps/main/search-config-v2.json
diff --git a/toolkit/components/search/docs/SearchConfigurationSchemaArchive.rst b/toolkit/components/search/docs/SearchConfigurationSchemaArchive.rst
index 3b5e8dc82c47..28be7b0f3cae 100644
--- a/toolkit/components/search/docs/SearchConfigurationSchemaArchive.rst
+++ b/toolkit/components/search/docs/SearchConfigurationSchemaArchive.rst
@@ -3,7 +3,7 @@ Search Configuration Schema (Archived)
 ======================================
 
 This document outlines the details of the schema and how the various sub-parts
-interact. For the full fields and descriptions, please see the `schema itself`_.
+interact. For the full fields and descriptions, please see the :searchfox:`schema itself <toolkit/components/search/schema/>`.
 
 .. note::
     In the examples, only relevant properties are displayed.
@@ -122,9 +122,9 @@ of the extension, ``web``.
 
 If a locale is not provided, ``webExtension.locales`` is set to ``default``.
 
-`Search Extensions directory <https://searchfox.org/firefox-main/source/browser/components/search/extensions>`__
+:searchfox:`Search Extensions directory <browser/components/search/extensions>`
 
-`Example of a locales directory <https://searchfox.org/firefox-main/source/browser/components/search/extensions/wikipedia/_locales>`__
+:searchfox:`Example of a locales directory <browser/components/search/extensions/wikipedia/_locales>`
 
 
 Special Attributes
@@ -581,5 +581,4 @@ Example:
 
 This would result in the order: ``engine2@ext, engine1@ext, engine3@ext``.
 
-.. _schema itself: https://searchfox.org/firefox-main/source/toolkit/components/search/schema/
 .. _the version comparator: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format
diff --git a/toolkit/components/search/docs/SearchEngineConfiguration.rst b/toolkit/components/search/docs/SearchEngineConfiguration.rst
index 8f1da41abda8..30a3ea6533b8 100644
--- a/toolkit/components/search/docs/SearchEngineConfiguration.rst
+++ b/toolkit/components/search/docs/SearchEngineConfiguration.rst
@@ -31,14 +31,13 @@ Configuration Schema
 ====================
 
 The configuration format is defined via a `JSON schema`_. The search engine
-configuration schema is `stored in mozilla-central`_ and is uploaded to the
+configuration schema is :searchfox:`stored in mozilla-central <toolkit/components/search/schema/>` and is uploaded to the
 Remote Settings server at convenient times after it changes.
 
 An outline of the schemas may be found on the `Search Configuration Schema`_ page.
 
 .. _remote settings: /services/settings/index.html
 .. _JSON schema: https://json-schema.org/
-.. _stored in mozilla-central: https://searchfox.org/firefox-main/source/toolkit/components/search/schema/
 .. _Search Configuration Schema: SearchConfigurationSchema.html
 .. _viewed live: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-config-v2/records
 .. _search-config-icons: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-config-icons/records
diff --git a/toolkit/components/search/docs/SearchEngineConfigurationArchive.rst b/toolkit/components/search/docs/SearchEngineConfigurationArchive.rst
index e17f36734438..70475f226ee0 100644
--- a/toolkit/components/search/docs/SearchEngineConfigurationArchive.rst
+++ b/toolkit/components/search/docs/SearchEngineConfigurationArchive.rst
@@ -27,7 +27,7 @@ Configuration Schema
 ====================
 
 The configuration format is defined via a `JSON schema`_. The search engine
-configuration schema is `stored in mozilla-central`_ and is uploaded to the
+configuration schema is :searchfox:`stored in mozilla-central <toolkit/components/search/schema/>` and is uploaded to the
 Remote Settings server at convenient times after it changes.
 
 An outline of the schema may be found on the `Search Configuration Schema`_ page.
@@ -66,7 +66,6 @@ related. As a result several situations may occur:
 
 .. _the remote settings: /services/settings/index.html
 .. _JSON schema: https://json-schema.org/
-.. _stored in mozilla-central: https://searchfox.org/firefox-main/source/toolkit/components/search/schema/
 .. _Search Configuration Schema: SearchConfigurationSchema.html
 .. _viewed live: https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-config/records
 .. _Normandy: /toolkit/components/normandy/normandy/services.html
diff --git a/toolkit/components/search/docs/SearchEnginesArchive.rst b/toolkit/components/search/docs/SearchEnginesArchive.rst
index dbc772a22e4d..67889c2b9ec0 100644
--- a/toolkit/components/search/docs/SearchEnginesArchive.rst
+++ b/toolkit/components/search/docs/SearchEnginesArchive.rst
@@ -28,8 +28,7 @@ Engines when referring to Add-ons Search Engines.
    https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions
 
 The list of Add-on Search Engines provided by Firefox and their extension files
-can be found in `mozilla-central/browser/components/search/extensions
-<https://searchfox.org/firefox-main/source/browser/components/search/extensions>`__.
+can be found in :searchfox:`mozilla-central/browser/components/search/extensions <browser/components/search/extensions>`.
 Within each Add-on Search Engine folder, there is a manifest.json file. One of the
 keys in that manifest.json file is `chrome_settings_overrides`, whose value is an object
 that describes how to construct the url, images, strings, icon, etc. Here’s an example of
diff --git a/toolkit/components/search/docs/SearchServiceHighlevelOverview.rst b/toolkit/components/search/docs/SearchServiceHighlevelOverview.rst
index c98f9065695c..1a1f32856fb0 100644
--- a/toolkit/components/search/docs/SearchServiceHighlevelOverview.rst
+++ b/toolkit/components/search/docs/SearchServiceHighlevelOverview.rst
@@ -30,7 +30,7 @@ described by number 1 below.
 
 1. When the user opens the Firefox Browser, the code starts to build the browser
    UI components. During this startup phase, we have various systems making
-   calls to the ``SearchService``. E.g. `browser.js <https://searchfox.org/mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515/browser/base/content/browser.js#3325>`_
+   calls to the ``SearchService``. E.g. :searchfox:`browser.js <mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515:browser/base/content/browser.js#3325>`
    calls ``SearchService.getDefault`` to fetch the default Search Engine.
 
 2. The ``SearchService`` needs information from ``Extension System``,
@@ -38,8 +38,8 @@ described by number 1 below.
    the right order and to return the list of engines to its callers.
 
    a) First, the ``SearchService`` makes a request for the search configuration.
-   ``SearchService`` calls `SearchEngineSelector.fetchEngineConfiguration <https://searchfox.org/mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515/toolkit/components/search/SearchService.sys.mjs#2602>`_
-   which makes a call to `Remote Settings <https://searchfox.org/mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515/toolkit/components/search/SearchEngineSelector.sys.mjs#119>`_
+   ``SearchService`` calls :searchfox:`SearchEngineSelector.fetchEngineConfiguration <mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515:toolkit/components/search/SearchService.sys.mjs#2602>`
+   which makes a call to :searchfox:`Remote Settings <mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515:toolkit/components/search/SearchEngineSelector.sys.mjs#119>`
    for the search configuration. Remote Settings does not fetch the search
    configuration from the remote database on startup. Instead Remote Settings
    tries to load the :searchfox:`search configuration dump file <services/settings/dumps/main/search-config-v2.json>`
@@ -48,13 +48,13 @@ described by number 1 below.
    remote database when necessary. By connecting after startup, it avoids
    a potential network request that could delay startup.
 
-   b) Second, the ``SearchService`` `loads the JSON file <https://searchfox.org/mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515/toolkit/components/search/SearchService.sys.mjs#1368>`_
-   containing the `SearchSettings <https://searchfox.org/firefox-main/source/toolkit/components/search/SearchSettings.sys.mjs>`_.
+   b) Second, the ``SearchService`` :searchfox:`loads the JSON file <mozilla-central/rev/47db1be98f8069b387ce07dcbea22d09f1854515:toolkit/components/search/SearchService.sys.mjs#1368>`
+   containing the :searchfox:`SearchSettings <toolkit/components/search/SearchSettings.sys.mjs>`.
    This JSON file contains Search Engine metadata that is saved on the user's
    computer. It's information that helps the ``SearchService`` remember the
    user's custom settings for the Search Engines.
 
-   c) Third, the `Extension System <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/browser/components/extensions/parent/ext-chrome-settings-overrides.js#536>`_
+   c) Third, the :searchfox:`Extension System <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:browser/components/extensions/parent/ext-chrome-settings-overrides.js#536>`
    passes the extension data to the ``SearchService``. At this point, the
    ``SearchService`` only installs user installed search extensions.
 
diff --git a/toolkit/components/search/docs/SearchServiceHighlevelOverviewArchive.rst b/toolkit/components/search/docs/SearchServiceHighlevelOverviewArchive.rst
index 4f6d32d29912..e1e4638424ec 100644
--- a/toolkit/components/search/docs/SearchServiceHighlevelOverviewArchive.rst
+++ b/toolkit/components/search/docs/SearchServiceHighlevelOverviewArchive.rst
@@ -30,7 +30,7 @@ described by number 1 below.
 
 1. When the user opens the Firefox Browser, the code starts to build the browser
    UI components. During this startup phase, we have various systems making
-   calls to the ``SearchService``. E.g. `browser.js <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/browser/base/content/browser.js#3797>`_
+   calls to the ``SearchService``. E.g. :searchfox:`browser.js <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:browser/base/content/browser.js#3797>`
    calls ``SearchService.getDefault`` to fetch the default Search Engine.
 
 2. The ``SearchService`` needs information from ``System Add-ons``,
@@ -38,8 +38,8 @@ described by number 1 below.
    the right order and to return the list of engines to its callers.
 
    a) First, the ``SearchService`` makes a request for the search configuration.
-   ``SearchService`` calls `SearchEngineSelector.fetchEngineConfiguration <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/toolkit/components/search/SearchService.sys.mjs#2247>`_
-   which makes a call to `Remote Settings <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/toolkit/components/search/SearchEngineSelector.sys.mjs#129>`_
+   ``SearchService`` calls :searchfox:`SearchEngineSelector.fetchEngineConfiguration <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:toolkit/components/search/SearchService.sys.mjs#2247>`
+   which makes a call to :searchfox:`Remote Settings <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:toolkit/components/search/SearchEngineSelector.sys.mjs#129>`
    for the search configuration. Remote Settings does not fetch the search
    configuration from the remote database on startup. Instead Remote Settings
    tries to load the :searchfox:`search configuration dump file <services/settings/dumps/main/search-config.json>`
@@ -48,18 +48,18 @@ described by number 1 below.
    remote database when necessary. By connecting after startup, it avoids
    a potential network request that could delay startup.
 
-   b) Second, the ``SearchService`` `fetches a JSON file <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/toolkit/components/search/SearchService.sys.mjs#1296-1297>`_
-   from the `SearchSettings <https://searchfox.org/firefox-main/source/toolkit/components/search/SearchSettings.sys.mjs>`_.
+   b) Second, the ``SearchService`` :searchfox:`fetches a JSON file <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:toolkit/components/search/SearchService.sys.mjs#1296-1297>`
+   from the :searchfox:`SearchSettings <toolkit/components/search/SearchSettings.sys.mjs>`.
    This JSON file contains Search Engine metadata that is saved on the user's
    computer. It's information that helps the ``SearchService`` remember the
    user's custom settings for the Search Engines.
 
-   c) Third, the `System Add-ons <https://searchfox.org/mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06/browser/components/extensions/parent/ext-chrome-settings-overrides.js#536>`_
+   c) Third, the :searchfox:`System Add-ons <mozilla-central/rev/cb6f8d7b1f1782b9d4b2ee7312de1dcc284aaf06:browser/components/extensions/parent/ext-chrome-settings-overrides.js#536>`
    passes the extension data to the ``SearchService``. At this point, the
    ``SearchService`` only installs user installed search extensions. For the
-   Application Provided engines we create those when ``SearchService`` calls `_makeEngineFromConfig <https://searchfox.org/mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b/toolkit/components/search/SearchService.sys.mjs#3421-3440>`_.
+   Application Provided engines we create those when ``SearchService`` calls :searchfox:`_makeEngineFromConfig <mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b:toolkit/components/search/SearchService.sys.mjs#3421-3440>`.
    Then ``_makeEngineFromConfig`` will create a new ``AddonSearchEngine``.
-   When the `AddonSearchEngine.init <https://searchfox.org/mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b/toolkit/components/search/AddonSearchEngine.sys.mjs#83-87,89>`_
+   When the :searchfox:`AddonSearchEngine.init <mozilla-central/rev/3002762e41363de8ee9ca80196d55e79651bcb6b:toolkit/components/search/AddonSearchEngine.sys.mjs#83-87,89>`
    method is called, it combines both the extension and search configuration
    data to create the correct engine for the user based on locale, region and
    other information.
diff --git a/toolkit/components/sessionstore/docs/collection.rst b/toolkit/components/sessionstore/docs/collection.rst
index b510459c62b3..22983175ba05 100644
--- a/toolkit/components/sessionstore/docs/collection.rst
+++ b/toolkit/components/sessionstore/docs/collection.rst
@@ -100,11 +100,11 @@ The steps for collecting data are roughly as follows:
 #. When the timer fires it becomes unset and every document marked as having changes is inspected, and the changed data is collected.
 #. Then for each document, an increment is sent to update the session store in the parent with.
 
-These document tree fragments are managed in Gecko by a `PBrowser <https://searchfox.org/firefox-main/source/dom/ipc/PBrowser.ipdl>`__ IPDL actor, which in turn is managed by the `PContent <https://searchfox.org/firefox-main/source/dom/ipc/PContent.ipdl>`__ IPDL actor. These actors facilitate communication between the content processes containing documents and the parent process running the UI.
+These document tree fragments are managed in Gecko by a :searchfox:`PBrowser <dom/ipc/PBrowser.ipdl>` IPDL actor, which in turn is managed by the :searchfox:`PContent <dom/ipc/PContent.ipdl>` IPDL actor. These actors facilitate communication between the content processes containing documents and the parent process running the UI.
 
-To encapsulate the framework of session store data collection, the operations for incrementally transmitting data to put in the session store is handled by the `PSessionStore <https://searchfox.org/firefox-main/source/toolkit/components/sessionstore/PSessionStore.ipdl>`__ IPDL actor, which is managed by the PBrowser IPDL actor.
+To encapsulate the framework of session store data collection, the operations for incrementally transmitting data to put in the session store is handled by the :searchfox:`PSessionStore <toolkit/components/sessionstore/PSessionStore.ipdl>` IPDL actor, which is managed by the PBrowser IPDL actor.
 
-The C++ class `SessionStoreChangeListener <https://searchfox.org/firefox-main/source/toolkit/components/sessionstore/SessionStoreChangeListener.h>`__ registers event handlers that listen to changes in the document tree and manages the timer. The timer enables buffering changes to make sure that the cross-process communication is throttled as well as only collecting when a change has happened. The buffering period can be controlled by the pref ``browser.sessionstore.interval``. The class also keeps track of documents and collects data from them, as well as sending the collected data to the parent process using PSessionStore.
+The C++ class :searchfox:`SessionStoreChangeListener <toolkit/components/sessionstore/SessionStoreChangeListener.h>` registers event handlers that listen to changes in the document tree and manages the timer. The timer enables buffering changes to make sure that the cross-process communication is throttled as well as only collecting when a change has happened. The buffering period can be controlled by the pref ``browser.sessionstore.interval``. The class also keeps track of documents and collects data from them, as well as sending the collected data to the parent process using PSessionStore.
 
 ----------------------
 Incremental Collection
@@ -286,13 +286,13 @@ Collecting Data in the Parent Process
 Collecting Session Storage
 --------------------------
 
-Session Storage is accessed through the `BackgroundSessionStorageManager <https://searchfox.org/firefox-main/source/dom/storage/SessionStorageManager.h>`__ and by calling ``BackgroundSessionStorageManager::GetData``.
+Session Storage is accessed through the :searchfox:`BackgroundSessionStorageManager <dom/storage/SessionStorageManager.h>` and by calling ``BackgroundSessionStorageManager::GetData``.
 
 --------------------------
 Collecting Session History
 --------------------------
 
-Session history is collected by calling the ``SessionHistory.collectFromParent`` function in the `Session History module <https://searchfox.org/firefox-main/source/toolkit/modules/sessionstore/SessionHistory.sys.mjs>`__. This is the responsibility of the embedder to collect and is not pushed to the embedder.
+Session history is collected by calling the ``SessionHistory.collectFromParent`` function in the :searchfox:`Session History module <toolkit/modules/sessionstore/SessionHistory.sys.mjs>`. This is the responsibility of the embedder to collect and is not pushed to the embedder.
 
 .. _interacting-with-sessionstore:
 
@@ -300,7 +300,7 @@ Session history is collected by calling the ``SessionHistory.collectFromParent``
 Interacting With Session Store Collection
 =========================================
 
-To integrate with session store collection an embedder needs to implement the `nsISessionStoreFunctions <https://searchfox.org/firefox-main/source/toolkit/components/sessionstore/nsISessionStoreFunctions.idl>`__ interface.
+To integrate with session store collection an embedder needs to implement the :searchfox:`nsISessionStoreFunctions <toolkit/components/sessionstore/nsISessionStoreFunctions.idl>` interface.
 
 .. code-block:: webidl
 
@@ -346,7 +346,7 @@ The actual format of the data stored is not relevant insofar that its use is bas
 Structure of data pushed by ``UpdateSessionStore``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In `SessionStoreUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/SessionStoreUtils.webidl>`__ the structure of collected data is defined as:
+In :searchfox:`SessionStoreUtils.webidl <dom/chrome-webidl/SessionStoreUtils.webidl>` the structure of collected data is defined as:
 
 .. code-block:: webidl
 
@@ -427,7 +427,7 @@ The collected form data builds up a similar tree of data for the document tree a
     }
   }
 
-``FormData`` and ``File`` are the same data as their web exposed counterparts in `FormData.webidl <https://searchfox.org/firefox-main/source/dom/webidl/FormData.webidl>`__ and `File.webidl <https://searchfox.org/firefox-main/source/dom/webidl/File.webidl>`__.
+``FormData`` and ``File`` are the same data as their web exposed counterparts in :searchfox:`FormData.webidl <dom/webidl/FormData.webidl>` and :searchfox:`File.webidl <dom/webidl/File.webidl>`.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Structure of data pushed by ``UpdateSessionStoreForStorage``
diff --git a/toolkit/components/sessionstore/docs/restoredata.rst b/toolkit/components/sessionstore/docs/restoredata.rst
index 9170af953e60..80124b0f8ab3 100644
--- a/toolkit/components/sessionstore/docs/restoredata.rst
+++ b/toolkit/components/sessionstore/docs/restoredata.rst
@@ -4,8 +4,8 @@ Restoring Data
 
 Restoring consists of two steps:
 
-1) Restore session history, which is handled in the `Session History module <https://searchfox.org/firefox-main/source/toolkit/modules/sessionstore/SessionHistory.sys.mjs>`__.
-2) Restore the other collected data, which is handled in `SessionStoreUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/SessionStoreUtils.webidl>`__ and `SessionStoreUtils.cpp <https://searchfox.org/firefox-main/source/toolkit/components/sessionstore/SessionStoreUtils.cpp>`__
+1) Restore session history, which is handled in the :searchfox:`Session History module <toolkit/modules/sessionstore/SessionHistory.sys.mjs>`.
+2) Restore the other collected data, which is handled in :searchfox:`SessionStoreUtils.webidl <dom/chrome-webidl/SessionStoreUtils.webidl>` and :searchfox:`SessionStoreUtils.cpp <toolkit/components/sessionstore/SessionStoreUtils.cpp>`
 
 The reason for this is that restoring the session history implies navigating to the location of the restored active session history entry, and it's only possible to restore the state of the page after that navigation is complete.
 
@@ -56,7 +56,7 @@ Calling ``SessionHistory.restoreFromParent``
 * ``history`` is the session history object
 * ``tabData`` is the tabdata including all history entries.
 
-The format of ``history`` isn't relevant, but it is the idl interface `nsISHistory <https://searchfox.org/firefox-main/source/docshell/shistory/nsISHistory.idl>`__.
+The format of ``history`` isn't relevant, but it is the idl interface :searchfox:`nsISHistory <docshell/shistory/nsISHistory.idl>`.
 
 The format of ``tabData`` is an object literal with the corresponding interface:
 
diff --git a/toolkit/components/sessionstore/docs/utils.rst b/toolkit/components/sessionstore/docs/utils.rst
index 2a44772a000c..4caa8c3aecc4 100644
--- a/toolkit/components/sessionstore/docs/utils.rst
+++ b/toolkit/components/sessionstore/docs/utils.rst
@@ -6,13 +6,13 @@ Session Store Utilities
 SessionStoreUtils
 -----------------
 
-`SessionStoreUtils.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/SessionStoreUtils.webidl>`__ and its implementation `SessionStoreUtils.cpp <https://searchfox.org/firefox-main/source/toolkit/components/sessionstore/SessionStoreUtils.cpp>`__ contain several of the key functions and types for implementing session restore. In particular the functions that extracts or restores states from/to a document.
+:searchfox:`SessionStoreUtils.webidl <dom/chrome-webidl/SessionStoreUtils.webidl>` and its implementation :searchfox:`SessionStoreUtils.cpp <toolkit/components/sessionstore/SessionStoreUtils.cpp>` contain several of the key functions and types for implementing session restore. In particular the functions that extracts or restores states from/to a document.
 
 -------------
 nsFrameLoader
 -------------
 
-`nsFrameLoader.cpp <https://searchfox.org/firefox-main/source/dom/base/nsFrameLoader.webidl>`__ and `nsFrameLoader.webidl <https://searchfox.org/firefox-main/source/dom/chrome-webidl/FrameLoader.webidl>`__ defines important functionality for session store data collection that enables state flushing. Flushing is required because of the buffering controlled by ``browser.sessionstore.interval``, since there are occasions where waiting for the collection to buffer isn't desired, e.g closing a tab, duplicating a tab, etc. ``Promise<undefined> FrameLoader.requestTabStateFlush()`` initiates a flush, which will perform the steps described in :ref:`collecting-data`, but without buffering. Once the collection is finished, the promise resolves. ``requestTabStateFlush`` can be called either from JavaScript or C++. ``void nsFrameLoader::RequestFinalTabStateFlush()`` on the other hand is called by the platform when a tab is closing, and tries to ensure that whatever data has been collected is sent to the session store. When this has finished, the observer service will notify listeners of the ``"browser-shutdown-tabstate-updated"`` topic.
+:searchfox:`nsFrameLoader.cpp <dom/base/nsFrameLoader.webidl>` and :searchfox:`nsFrameLoader.webidl <dom/chrome-webidl/FrameLoader.webidl>` defines important functionality for session store data collection that enables state flushing. Flushing is required because of the buffering controlled by ``browser.sessionstore.interval``, since there are occasions where waiting for the collection to buffer isn't desired, e.g closing a tab, duplicating a tab, etc. ``Promise<undefined> FrameLoader.requestTabStateFlush()`` initiates a flush, which will perform the steps described in :ref:`collecting-data`, but without buffering. Once the collection is finished, the promise resolves. ``requestTabStateFlush`` can be called either from JavaScript or C++. ``void nsFrameLoader::RequestFinalTabStateFlush()`` on the other hand is called by the platform when a tab is closing, and tries to ensure that whatever data has been collected is sent to the session store. When this has finished, the observer service will notify listeners of the ``"browser-shutdown-tabstate-updated"`` topic.
 
 The main difference between ``RequestTabStateFlush`` and ``RequestFinalTabStateFlush`` is that the latter is very much a best effort functionality, and data loss cannot be guaranteed to be avoided. On the other hand, using ``RequestTabStateFlush`` and awaiting the promise might take an relatively long time, which might make that not suitable in all situations.
 
diff --git a/toolkit/components/telemetry/docs/data/main-ping.rst b/toolkit/components/telemetry/docs/data/main-ping.rst
index 6277cfb5f80b..8904dec72721 100644
--- a/toolkit/components/telemetry/docs/data/main-ping.rst
+++ b/toolkit/components/telemetry/docs/data/main-ping.rst
@@ -131,7 +131,7 @@ This format was adopted in Firefox 51 via bug 1218576.
 
 scalars and keyedScalars
 ~~~~~~~~~~~~~~~~~~~~~~~~
-This section contains the Scalars that are valid for the current platform. Scalars are only submitted if data was added to them, and are only reported with subsession pings. The recorded scalars are described in the `Scalars.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Scalars.yaml>`_ file. The ``info.revision`` field indicates the revision of the file that describes the reported scalars.
+This section contains the Scalars that are valid for the current platform. Scalars are only submitted if data was added to them, and are only reported with subsession pings. The recorded scalars are described in the :searchfox:`Scalars.yaml <toolkit/components/telemetry/Scalars.yaml>` file. The ``info.revision`` field indicates the revision of the file that describes the reported scalars.
 
 simpleMeasurements
 ------------------
@@ -181,13 +181,13 @@ The number of times the system failed to lock the user profile.
 
 activeTicks
 ~~~~~~~~~~~
-Integer count of the number of five-second intervals ('ticks') the user was considered 'active' (sending UI events to the window). An extra event is fired immediately when the user becomes active after being inactive. This is for some mouse and gamepad events, and all touch, keyboard, wheel, and pointer events (see `EventStateManager.cpp <https://searchfox.org/firefox-main/source/dom/events/EventStateManager.cpp#504>`__).
+Integer count of the number of five-second intervals ('ticks') the user was considered 'active' (sending UI events to the window). An extra event is fired immediately when the user becomes active after being inactive. This is for some mouse and gamepad events, and all touch, keyboard, wheel, and pointer events (see :searchfox:`EventStateManager.cpp <dom/events/EventStateManager.cpp#504>`).
 This measure might be useful to give a trend of how much a user actually interacts with the browser when compared to overall session duration. It does not take into account whether or not the window has focus or is in the foreground. Just if it is receiving these interaction events.
 Note that in ``main`` pings, this measure is reset on subsession splits, while in ``saved-session`` pings it covers the whole browser session.
 
 histograms
 ----------
-This section contains the histograms that are valid for the current platform. ``Flag`` histograms are always created and submitted with a default value of ``false`` if a value of ``true`` is not recorded during the time period. Other histogram types (see :ref:`choosing-histogram-type`) are not created nor submitted if no data was added to them. The type and format of the reported histograms is described by the ``Histograms.json`` file. Its most recent version is available `here <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Histograms.json>`__. The ``info.revision`` field indicates the revision of the file that describes the reported histograms.
+This section contains the histograms that are valid for the current platform. ``Flag`` histograms are always created and submitted with a default value of ``false`` if a value of ``true`` is not recorded during the time period. Other histogram types (see :ref:`choosing-histogram-type`) are not created nor submitted if no data was added to them. The type and format of the reported histograms is described by the ``Histograms.json`` file. Its most recent version is available :searchfox:`here <toolkit/components/telemetry/Histograms.json>`. The ``info.revision`` field indicates the revision of the file that describes the reported histograms.
 
 keyedHistograms
 ---------------
diff --git a/toolkit/components/telemetry/docs/data/new-profile-ping.rst b/toolkit/components/telemetry/docs/data/new-profile-ping.rst
index 3f5557c5f4ef..d47f721b1c7b 100644
--- a/toolkit/components/telemetry/docs/data/new-profile-ping.rst
+++ b/toolkit/components/telemetry/docs/data/new-profile-ping.rst
@@ -53,7 +53,7 @@ scalars
 This section contains the Scalars that are valid for the ``new-profile`` ping,
 that is the ``record_into_store`` list contains ``new-profile``.
 Scalars are only submitted if data was added to them.
-The recorded scalars are described in the `Scalars.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Scalars.yaml>`_ file.
+The recorded scalars are described in the :searchfox:`Scalars.yaml <toolkit/components/telemetry/Scalars.yaml>` file.
 
 Duplicate pings
 ---------------
diff --git a/toolkit/components/telemetry/docs/internals/integration_tests/index.rst b/toolkit/components/telemetry/docs/internals/integration_tests/index.rst
index 8b7aab4689a9..22dfdc54981b 100644
--- a/toolkit/components/telemetry/docs/internals/integration_tests/index.rst
+++ b/toolkit/components/telemetry/docs/internals/integration_tests/index.rst
@@ -9,7 +9,7 @@ use automation to mimic user behavior.
 The integration test suite for Firefox Client Telemetry runs on CI `tier 1 <https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy>`_
 with treeherder symbol `tt(c)`
 and is checked in to version control at mozilla-central under
-`toolkit/components/telemetry/tests/marionette/tests/client <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/tests/marionette/tests/client/>`_.
+:searchfox:`toolkit/components/telemetry/tests/marionette/tests/client <toolkit/components/telemetry/tests/marionette/tests/client/>`.
 
 Test Main Tab Scalars
 ---------------------
diff --git a/toolkit/components/telemetry/docs/obsolete/collection/events.rst b/toolkit/components/telemetry/docs/obsolete/collection/events.rst
index 6542d592fd46..6d773476293d 100644
--- a/toolkit/components/telemetry/docs/obsolete/collection/events.rst
+++ b/toolkit/components/telemetry/docs/obsolete/collection/events.rst
@@ -85,7 +85,7 @@ The YAML definition file
 ========================
 
 Any event recorded into Firefox Telemetry must be registered before it can be recorded.
-For any code that ships as part of Firefox that happens in `Events.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Events.yaml>`_.
+For any code that ships as part of Firefox that happens in :searchfox:`Events.yaml <toolkit/components/telemetry/Events.yaml>`.
 
 The probes in the definition file are represented in a fixed-depth, three-level structure. The first level contains *category* names (grouping multiple events together), the second level contains *event* names, under which the events properties are listed. E.g.:
 
diff --git a/toolkit/components/telemetry/docs/obsolete/collection/histograms.rst b/toolkit/components/telemetry/docs/obsolete/collection/histograms.rst
index 8e3c635e1207..b63797ab1614 100644
--- a/toolkit/components/telemetry/docs/obsolete/collection/histograms.rst
+++ b/toolkit/components/telemetry/docs/obsolete/collection/histograms.rst
@@ -103,7 +103,7 @@ Note that when you need to record for a small set of known keys, using separate
 Declaring a Histogram
 =====================
 
-Histograms should be declared in the `Histograms.json <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Histograms.json>`_ file. These declarations are checked for correctness at `compile time <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/gen_histogram_data.py>`_ and used to generate C++ code.
+Histograms should be declared in the :searchfox:`Histograms.json <toolkit/components/telemetry/Histograms.json>` file. These declarations are checked for correctness at :searchfox:`compile time <toolkit/components/telemetry/gen_histogram_data.py>` and used to generate C++ code.
 
 The following is a sample histogram declaration from ``Histograms.json`` for a histogram named ``MEMORY_RESIDENT`` which tracks the amount of resident memory used by a process:
 
@@ -254,7 +254,7 @@ Telemetry Histograms do not record values greater than 2^31, instead clamping th
 Adding a JavaScript Probe
 =========================
 
-A Telemetry probe is the code that measures and stores values in a histogram. Probes in privileged JavaScript code can make use of the `nsITelemetry <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/nsITelemetry.idl>`_ interface to get references to histogram objects. A new value is recorded in the histogram by calling ``add`` on the histogram object:
+A Telemetry probe is the code that measures and stores values in a histogram. Probes in privileged JavaScript code can make use of the :searchfox:`nsITelemetry <toolkit/components/telemetry/nsITelemetry.idl>` interface to get references to histogram objects. A new value is recorded in the histogram by calling ``add`` on the histogram object:
 
 .. code-block:: js
 
@@ -273,7 +273,7 @@ Note that ``nsITelemetry.getHistogramById()`` will throw an ``NS_ERROR_FAILURE``
 Adding a C++ Probe
 ==================
 
-Probes in native code can also use the `nsITelemetry <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/nsITelemetry.idl>`_ interface, but the helper functions declared in `Telemetry.h <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Telemetry.h>`_ are more convenient:
+Probes in native code can also use the :searchfox:`nsITelemetry <toolkit/components/telemetry/nsITelemetry.idl>` interface, but the helper functions declared in :searchfox:`Telemetry.h <toolkit/components/telemetry/Telemetry.h>` are more convenient:
 
 .. code-block:: cpp
 
diff --git a/toolkit/components/telemetry/docs/obsolete/collection/scalars.rst b/toolkit/components/telemetry/docs/obsolete/collection/scalars.rst
index 76b9be2f42ac..4971b88929cc 100644
--- a/toolkit/components/telemetry/docs/obsolete/collection/scalars.rst
+++ b/toolkit/components/telemetry/docs/obsolete/collection/scalars.rst
@@ -23,8 +23,8 @@ The serialized scalar data is submitted with the :doc:`main pings <../../data/ma
 
 The API
 =======
-Scalar probes can be managed either through the `nsITelemetry interface <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/core/nsITelemetry.idl>`_
-or the `C++ API <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/core/Telemetry.h>`_.
+Scalar probes can be managed either through the :searchfox:`nsITelemetry interface <toolkit/components/telemetry/core/nsITelemetry.idl>`
+or the :searchfox:`C++ API <toolkit/components/telemetry/core/Telemetry.h>`.
 
 JS API
 ------
@@ -94,7 +94,7 @@ Example:
 
 C++ API
 -------
-Probes in native code can use the more convenient helper functions declared in `Telemetry.h <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/core/Telemetry.h>`_:
+Probes in native code can use the more convenient helper functions declared in :searchfox:`Telemetry.h <toolkit/components/telemetry/core/Telemetry.h>`:
 
 .. code-block:: cpp
 
@@ -116,7 +116,7 @@ Probes in native code can use the more convenient helper functions declared in `
 The YAML definition file
 ========================
 Scalar probes are required to be registered, both for validation and transparency reasons,
-in the `Scalars.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Scalars.yaml>`_
+in the :searchfox:`Scalars.yaml <toolkit/components/telemetry/Scalars.yaml>`
 definition file.
 
 The probes in the definition file are represented in a fixed-depth, two-level structure:
@@ -240,7 +240,7 @@ Making a scalar measurement is a two step process:
 
 Registering the scalar
 ----------------------
-Let's start by registering two probes in the `Scalars.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/Scalars.yaml>`_ definition file: a simple boolean scalar and a keyed unsigned scalar.
+Let's start by registering two probes in the :searchfox:`Scalars.yaml <toolkit/components/telemetry/Scalars.yaml>` definition file: a simple boolean scalar and a keyed unsigned scalar.
 
 .. code-block:: yaml
 
@@ -291,7 +291,7 @@ Changing the demo scalars from privileged JavaScript code is straightforward:
   // "ui.download_button_activated" scalar, by 1.
   Services.telemetry.keyedScalarAdd("ui.download_button_activated", "mouse_click", 1);
 
-More usage examples can be found in the tests covering the `JS Scalars API <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/tests/unit/test_TelemetryScalars.js>`_ and `child processes scalars <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/tests/unit/test_ChildScalars.js>`_.
+More usage examples can be found in the tests covering the :searchfox:`JS Scalars API <toolkit/components/telemetry/tests/unit/test_TelemetryScalars.js>` and :searchfox:`child processes scalars <toolkit/components/telemetry/tests/unit/test_ChildScalars.js>`.
 
 Using the C++ API
 -----------------
@@ -306,7 +306,7 @@ Native code can take advantage of Scalars as well, by including the ``Telemetry.
 
 The ``ScalarID`` enum is automatically generated by the build process, with an example being available `here <https://searchfox.org/mozilla-central/search?q=path%3ATelemetryScalarEnums.h&redirect=false>`_ .
 
-Other examples can be found in the `test coverage <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/tests/gtest/TestScalars.cpp>`_ for the scalars C++ API.
+Other examples can be found in the :searchfox:`test coverage <toolkit/components/telemetry/tests/gtest/TestScalars.cpp>` for the scalars C++ API.
 
 Version History
 ===============
diff --git a/toolkit/components/telemetry/docs/obsolete/collection/user-interactions.rst b/toolkit/components/telemetry/docs/obsolete/collection/user-interactions.rst
index 32bea8354444..01c9d1c378f7 100644
--- a/toolkit/components/telemetry/docs/obsolete/collection/user-interactions.rst
+++ b/toolkit/components/telemetry/docs/obsolete/collection/user-interactions.rst
@@ -111,7 +111,7 @@ The YAML definition file
 ========================
 
 Any User Interaction recorded into Firefox Telemetry must be registered before it can be recorded.
-For any code that ships as part of Firefox that happens in `UserInteractions.yaml <https://searchfox.org/firefox-main/source/toolkit/components/telemetry/UserInteractions.yaml>`_.
+For any code that ships as part of Firefox that happens in :searchfox:`UserInteractions.yaml <toolkit/components/telemetry/UserInteractions.yaml>`.
 
 The User Interactions in the definition file are represented in a fixed-depth, three-level structure.
 The first level contains *category* names (grouping multiple User Interactions together),
diff --git a/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst b/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
index aacf5da04121..b64e8ee4ca02 100644
--- a/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
+++ b/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
@@ -113,14 +113,14 @@ Test coverage
 
 Any data collection that you need to base decisions on needs to have test coverage. Using JS, you can access the recorded values for your data collection. You can use the following functions:
 
-- for scalars, `getSnapshotForScalars() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#90-102>`_
-  or `getSnapshotForKeyedScalars() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#104-116>`_
-- for histograms, `getSnapshotForHistograms() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#54-74>`_
-  or `getSnapshotForKeyedHistograms() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#76-88>`_
+- for scalars, :searchfox:`getSnapshotForScalars() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#90-102>`
+  or :searchfox:`getSnapshotForKeyedScalars() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#104-116>`
+- for histograms, :searchfox:`getSnapshotForHistograms() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#54-74>`
+  or :searchfox:`getSnapshotForKeyedHistograms() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#76-88>`
 
-  * Optionally, histogram objects have a `snapshot() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#285-287,313-315>`_ method.
+  * Optionally, histogram objects have a :searchfox:`snapshot() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#285-287,313-315>` method.
 
-- for events, `snapshotEvents() <https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/toolkit/components/telemetry/core/nsITelemetry.idl#542-558>`_
+- for events, :searchfox:`snapshotEvents() <mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9:toolkit/components/telemetry/core/nsITelemetry.idl#542-558>`
 
 If you need to test that pings were correctly passed to Telemetry, you can use `TelemetryArchiveTesting <https://searchfox.org/mozilla-central/search?q=TelemetryArchiveTesting&redirect=false>`_.
 
diff --git a/toolkit/crashreporter/docs/Using_the_Mozilla_symbol_server.rst b/toolkit/crashreporter/docs/Using_the_Mozilla_symbol_server.rst
index ab54e9f00072..76a7f2cb39bb 100644
--- a/toolkit/crashreporter/docs/Using_the_Mozilla_symbol_server.rst
+++ b/toolkit/crashreporter/docs/Using_the_Mozilla_symbol_server.rst
@@ -144,7 +144,7 @@ Downloading symbols on Linux / Mac OS X
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you are on Linux and running GDB 7.9 or newer, you can use the python script
-in `python/gdb-symbol-server/symbols.py <https://searchfox.org/firefox-main/source/python/gdb-symbol-server/symbols.py>`_
+in :searchfox:`python/gdb-symbol-server/symbols.py`
 to automatically fetch symbols. You will need to source this script before
 loading symbols (the part where it spends a few seconds loading each .so when
 you attach gdb). If you want to reload symbols, you can try:
diff --git a/toolkit/modules/docs/Region.rst b/toolkit/modules/docs/Region.rst
index 23ac799467c3..4ef354b919f3 100644
--- a/toolkit/modules/docs/Region.rst
+++ b/toolkit/modules/docs/Region.rst
@@ -17,10 +17,10 @@ callers should use ``Region.home``.
 Region Updating
 ---------------
 
-Firefox `uses a location service`_ that is provided by Mozilla. Firefox will
+Firefox :searchfox:`uses a location service <mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf:modules/libpref/init/all.js#3107>` that is provided by Mozilla. Firefox will
 attempt to check for region on first run of a new profile and
-`every 7 days thereafter`_. If an update check fails, then the update will be
-retried `after an hour`_ for a `maximum of three times`_.
+:searchfox:`every 7 days thereafter <mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf:toolkit/modules/Region.sys.mjs#106>`. If an update check fails, then the update will be
+retried :searchfox:`after an hour <mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf:toolkit/modules/Region.sys.mjs#32-40>` for a :searchfox:`maximum of three times <mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf:toolkit/modules/Region.sys.mjs#101>`.
 
 If the user is detected in a current region that is not their `home` region
 for a continuous period (current 2 weeks) then their `home` region
@@ -86,8 +86,3 @@ Run the script
 
 If you want to commit the new test data ~500 seems to be a reasonable
 number of data points to test before running into issues with the test length.
-
-.. _every 7 days thereafter: https://searchfox.org/mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf/toolkit/modules/Region.sys.mjs#106
-.. _uses a location service: https://searchfox.org/mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf/modules/libpref/init/all.js#3107
-.. _after an hour: https://searchfox.org/mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf/toolkit/modules/Region.sys.mjs#32-40
-.. _maximum of three times: https://searchfox.org/mozilla-central/rev/b22ec3f983078ff98b04cee7dafe4b90342a42bf/toolkit/modules/Region.sys.mjs#101
diff --git a/toolkit/mozapps/update/docs/BackgroundUpdates.rst b/toolkit/mozapps/update/docs/BackgroundUpdates.rst
index 682fe59a243d..aff96c3a181e 100644
--- a/toolkit/mozapps/update/docs/BackgroundUpdates.rst
+++ b/toolkit/mozapps/update/docs/BackgroundUpdates.rst
@@ -65,11 +65,10 @@ observe and control these settings.
 
 But there are some other pieces of state which absolutely must come from a
 profile, such as the telemetry client ID and logging level settings (see
-`BackgroundTasksUtils.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/backgroundtasks/BackgroundTasksUtils.sys.mjs>`__).
+:searchfox:`BackgroundTasksUtils.sys.mjs <toolkit/components/backgroundtasks/BackgroundTasksUtils.sys.mjs>`).
 
 This means that, in addition to our per-installation prefs, we also need
-to be able to identify and load a profile. To do that, we leverage `the profile
-service <https://searchfox.org/firefox-main/source/toolkit/profile/nsIToolkitProfileService.idl>`__
+to be able to identify and load a profile. To do that, we leverage :searchfox:`the profile service <toolkit/profile/nsIToolkitProfileService.idl>`
 to determine what the default profile for the installation would be if we were
 running a normal browser session, and the background updater always uses it.
 
@@ -137,7 +136,7 @@ API <https://docs.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-star
 on macOS this will use
 `launchd <https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html>`__.
 For platform-specific scheduling details, see the
-`TaskScheduler.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/components/taskscheduler/TaskScheduler.sys.mjs>`__
+:searchfox:`TaskScheduler.sys.mjs <toolkit/components/taskscheduler/TaskScheduler.sys.mjs>`
 module.
 
 These background tasks are scheduled per OS user and run with that user’s
@@ -177,7 +176,7 @@ visible to users: see `bug 1775132
 
 After setting up this profile and reading all the configuration we need
 into it, the regular
-`UpdateService.sys.mjs <https://searchfox.org/firefox-main/source/toolkit/mozapps/update/UpdateService.sys.mjs>`__
+:searchfox:`UpdateService.sys.mjs <toolkit/mozapps/update/UpdateService.sys.mjs>`
 check process is initiated. To the greatest extent possible, this process is
 identical to what happens during any regular browsing session.
 
diff --git a/toolkit/mozapps/update/docs/InAppUpdateProcess.rst b/toolkit/mozapps/update/docs/InAppUpdateProcess.rst
index 3e1872129222..b34e609989fb 100644
--- a/toolkit/mozapps/update/docs/InAppUpdateProcess.rst
+++ b/toolkit/mozapps/update/docs/InAppUpdateProcess.rst
@@ -28,9 +28,9 @@ A file written to and read from, in part, to communicate between Firefox
 and the updater. The file will contain a short string indicating the
 current status. If that status is "failed", it will also contain an
 error code. A list of recognized status strings can be found
-`here <https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/toolkit/mozapps/update/nsIUpdateService.idl#177-190>`__.
+:searchfox:`here <mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6:toolkit/mozapps/update/nsIUpdateService.idl#177-190>`.
 The error codes used for failure status can be found
-`here <https://searchfox.org/mozilla-central/rev/3265b390bd5d08a5be520253ef71835bcb715f27/toolkit/mozapps/update/common/updatererrors.h>`__.
+:searchfox:`here <mozilla-central/rev/3265b390bd5d08a5be520253ef71835bcb715f27:toolkit/mozapps/update/common/updatererrors.h>`.
 
 Documentation
 -------------
diff --git a/tools/code-coverage/docs/index.rst b/tools/code-coverage/docs/index.rst
index f2377bc5832a..ba651d3f5ece 100644
--- a/tools/code-coverage/docs/index.rst
+++ b/tools/code-coverage/docs/index.rst
@@ -143,7 +143,7 @@ format for analysis. Anytime a code coverage run generates \*.gcda and
 permanently fail when it is running on a build that is instrumented with
 GCOV. To debug these issues without overloading ActiveData with garbage
 coverage data, open the file
-`taskcluster/gecko_taskgraph/transforms/test/__init__.py <https://searchfox.org/firefox-main/source/taskcluster/gecko_taskgraph/transforms/test/__init__.py#516>`__
+:searchfox:`taskcluster/gecko_taskgraph/transforms/test/__init__.py <taskcluster/gecko_taskgraph/transforms/test/__init__.py#516>`
 and add the following line,
 
 .. code:: python
diff --git a/tools/fuzzing/docs/fuzzing_interface.rst b/tools/fuzzing/docs/fuzzing_interface.rst
index 31a69f29095d..a67b380248af 100644
--- a/tools/fuzzing/docs/fuzzing_interface.rst
+++ b/tools/fuzzing/docs/fuzzing_interface.rst
@@ -179,14 +179,12 @@ The code using the fuzzing interface usually lives in a separate directory
 called ``fuzztest`` that is on the same level as gtests. If your component
 has no gtests, then a subdirectory either in tests or in your main directory
 will work. If such a directory does not exist yet in your component, then you
-need to create one with a suitable ``moz.build``. See  `the transport target
-for an example <https://searchfox.org/firefox-main/source/dom/media/webrtc/transport/fuzztest/moz.build>`__
+need to create one with a suitable ``moz.build``. See  :searchfox:`the transport target for an example <dom/media/webrtc/transport/fuzztest/moz.build>`
 
 In order to include the new subdirectory into the build process, you will
 also have to modify the toplevel ``moz.build`` file accordingly. For this
 purpose, you should add your directory to ``TEST_DIRS`` only if ``FUZZING_INTERFACES``
-is set. See again `the transport target for an example
-<https://searchfox.org/mozilla-central/rev/de7676288a78b70d2b9927c79493adbf294faad5/media/mtransport/moz.build#18-24>`__.
+is set. See again :searchfox:`the transport target for an example <mozilla-central/rev/de7676288a78b70d2b9927c79493adbf294faad5:media/mtransport/moz.build#18-24>`.
 
 How your code should look like
 ''''''''''''''''''''''''''''''
@@ -278,8 +276,7 @@ but the macro invocation is quite similar:
 
   MOZ_FUZZING_INTERFACE_STREAM(FuzzingInitMyTarget, FuzzingRunMyTarget, MyTarget);
 
-For a live example, see also the `implementation of the STUN fuzzing target
-<https://searchfox.org/firefox-main/source/dom/media/webrtc/transport/fuzztest/stun_parser_libfuzz.cpp>`__.
+For a live example, see also the :searchfox:`implementation of the STUN fuzzing target <dom/media/webrtc/transport/fuzztest/stun_parser_libfuzz.cpp>`.
 
 Add instrumentation to the code being tested
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -445,8 +442,7 @@ There are a few minor differences though:
 
    but there is no obligation for you to use these.
 
-For a live example, see also the `implementation of the StructuredCloneReader target
-<https://searchfox.org/firefox-main/source/js/src/fuzz-tests/testStructuredCloneReader.cpp>`__.
+For a live example, see also the :searchfox:`implementation of the StructuredCloneReader target <js/src/fuzz-tests/testStructuredCloneReader.cpp>`.
 
 
 Implementing in JS
@@ -470,7 +466,7 @@ As a rule of thumb, you should implement the target in JS if
 * or your target is not isolated enough for a C++ target and/or you need specific JS shell functions.
 
 
-There is an `example target <https://searchfox.org/firefox-main/source/js/src/shell/jsrtfuzzing/jsrtfuzzing-example.js>`__
+There is an :searchfox:`example target <js/src/shell/jsrtfuzzing/jsrtfuzzing-example.js>`
 in-tree that shows roughly how to implement such a fuzzing target.
 
 To run such a target, you must run the ``js`` (shell) binary instead of the
@@ -481,7 +477,7 @@ your fuzzing target, e.g.
 
    $ FUZZER=/path/to/jsrtfuzzing-example.js obj-asan/dist/bin/js --fuzzing-safe --no-threads -- <libFuzzer options here>
 
-More elaborate targets can be found in `js/src/fuzz-tests/ <https://searchfox.org/firefox-main/source/js/src/fuzz-tests/>`__.
+More elaborate targets can be found in :searchfox:`js/src/fuzz-tests/`.
 
 Troubleshooting
 ~~~~~~~~~~~~~~~
diff --git a/tools/fuzzing/docs/index.rst b/tools/fuzzing/docs/index.rst
index ea427a9c70c4..61849897134c 100644
--- a/tools/fuzzing/docs/index.rst
+++ b/tools/fuzzing/docs/index.rst
@@ -184,8 +184,7 @@ target similar to writing a gtest. This target will automatically be
 usable with libFuzzer and AFLFuzz. We offer a :ref:`comprehensive manual <Fuzzing Interface>`
 that describes how to write and utilize your own target.
 
-A simple example here is the `SDP parser
-target <https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/media/webrtc/signaling/fuzztest/sdp_parser_libfuzz.cpp#30>`__,
+A simple example here is the :searchfox:`SDP parser target <mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e:media/webrtc/signaling/fuzztest/sdp_parser_libfuzz.cpp#30>`,
 which tests the SipccSdpParser in our codebase.
 
 Shell-based Fuzzing
@@ -338,7 +337,7 @@ it on. Then, a fuzzer can hit the optimization code much more
 frequently, increasing the chance to find issues. Some examples from
 Firefox and SpiderMonkey:
 
-- The `FuzzingFunctions <https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/dom/webidl/FuzzingFunctions.webidl#15>`__
+- The :searchfox:`FuzzingFunctions <mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e:dom/webidl/FuzzingFunctions.webidl#15>`
   interface in the browser allows fuzzing tools to perform GC/CC, tune various
   settings related to garbage collection or enable features like accessibility
   mode. Being able to force a garbage collection at a specific time helped
@@ -361,7 +360,7 @@ cryptographic signatures. Being able to turn off the validation of these
 features as part of a fuzzing switch is extremely helpful.
 
 An example for such a checksum can be found in the
-`FlacDemuxer <https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/dom/media/flac/FlacDemuxer.cpp#494>`__.
+:searchfox:`FlacDemuxer <mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e:dom/media/flac/FlacDemuxer.cpp#494>`.
 
 Test Samples
 ~~~~~~~~~~~~
diff --git a/tools/lint/perfdocs/framework_gatherers.py b/tools/lint/perfdocs/framework_gatherers.py
index bfcb11ffd953..92d0b8c31feb 100644
--- a/tools/lint/perfdocs/framework_gatherers.py
+++ b/tools/lint/perfdocs/framework_gatherers.py
@@ -366,7 +366,7 @@ class RaptorGatherer(FrameworkGatherer):
                 elif key == "secondary_url":
                     result += f"   * **{sub_title}**: `<{description[key]}>`__\n"
                 elif key == "link searchfox":
-                    result += f"   * **{sub_title}**: `<{description[key]}>`__\n"
+                    result += f"   * **{sub_title}**: :searchfox:`{description[key]}`\n"
                 elif key in ["playback_pageset_manifest"]:
                     result += (
                         f"   * **{sub_title}**: "
diff --git a/tools/moztreedocs/docs/architecture.rst b/tools/moztreedocs/docs/architecture.rst
index 6f178a605855..485fc61da5e7 100644
--- a/tools/moztreedocs/docs/architecture.rst
+++ b/tools/moztreedocs/docs/architecture.rst
@@ -5,8 +5,8 @@ The documentation relies on Sphinx and many Sphinx extensions.
 
 The documentation code is in two main directories:
 
-* https://searchfox.org/firefox-main/source/docs
-* https://searchfox.org/firefox-main/source/tools/moztreedocs
+* :searchfox:`docs`
+* :searchfox:`tools/moztreedocs`
 
 Our documentation supports both rst & markdown syntaxes.
 
@@ -15,13 +15,13 @@ Configuration
 
 The main configuration file is:
 
-https://searchfox.org/firefox-main/source/docs/config.yml
+:searchfox:`docs/config.yml`
 
 It contains the categories, the redirects, the warnings and others configuration aspects.
 
 The dependencies are listed in:
 
-https://searchfox.org/firefox-main/source/tools/moztreedocs/requirements.in
+:searchfox:`tools/moztreedocs/requirements.in`
 
 Be aware that Python libraries stored in `third_party/python` are used in priority (not always for good reasons). See :ref:`Vendor the source of the Python package in-tree <python-vendor>` for more details.
 
@@ -30,7 +30,7 @@ Architecture
 ------------
 
 
-`mach_commands <https://searchfox.org/firefox-main/source/tools/moztreedocs/mach_commands.py>`__
+:searchfox:`mach_commands <tools/moztreedocs/mach_commands.py>`
 contains:
 
 * `mach doc` arguments managements
@@ -40,7 +40,7 @@ contains:
 * Starts the sphinx build (and serve it if the option is set)
 * Manages telemetry
 
-`docs/conf.py <https://searchfox.org/firefox-main/source/docs/conf.py>`__ defines:
+:searchfox:`docs/conf.py` defines:
 
 * The list of extensions
 * JS source paths
@@ -48,4 +48,4 @@ contains:
 
 At the end of the build documentation process, files will be uploaded to a CDN:
 
-https://searchfox.org/firefox-main/source/tools/moztreedocs/upload.py
+:searchfox:`tools/moztreedocs/upload.py`
diff --git a/tools/moztreedocs/docs/redirect.rst b/tools/moztreedocs/docs/redirect.rst
index c8f5f91e860b..66717bade307 100644
--- a/tools/moztreedocs/docs/redirect.rst
+++ b/tools/moztreedocs/docs/redirect.rst
@@ -5,7 +5,7 @@ We now have the ability to define redirects in-tree! This will allow us to
 refactor and move docs around to our hearts content without needing to worry
 about stale external URLs. To set up a redirect simply add a line to this file under ``redirects`` key:
 
-https://searchfox.org/firefox-main/source/docs/config.yml
+:searchfox:`docs/config.yml`
 
 Any request starting with the prefix on the left, will be rewritten to the prefix on the right by the server. So for example a request to
 ``/testing/marionette/marionette/index.html`` will be re-written to ``/testing/marionette/index.html``. Amazon's API only supports prefix redirects, so anything more complex isn't supported.
diff --git a/tools/profiler/docs/buffer.rst b/tools/profiler/docs/buffer.rst
index eb7ba52920c3..27d854fbe33a 100644
--- a/tools/profiler/docs/buffer.rst
+++ b/tools/profiler/docs/buffer.rst
@@ -29,7 +29,7 @@ Profile Buffer Terminology
 ProfilerParent
   The main profiler machinery is installed in the parent process. It uses IPC to
   communicate to the child processes. The PProfiler is the actor which is used
-  to communicate across processes to coordinate things. See `ProfilerParent.h`_. The
+  to communicate across processes to coordinate things. See :searchfox:`ProfilerParent.h <tools/profiler/public/ProfilerParent.h>`. The
   ProfilerParent uses the DestroyReleasedChunksAtOrBefore message to control the
   overall chunk limit.
 
@@ -38,7 +38,7 @@ ProfilerChild
   DestroyReleasedChunksAtOrBefore.
 
 Entry
-  This is an individual entry in the `ProfileBuffer.h`_,. These entry sizes are not
+  This is an individual entry in the :searchfox:`ProfileBuffer.h <tools/profiler/core/ProfileBuffer.h>`,. These entry sizes are not
   related to the chunks sizes. An individual entry can straddle two different chunks.
   An entry can contain various pieces of data, like markers, samples, and stacks.
 
@@ -61,9 +61,7 @@ Recycled chunk
 .. _ProfileChunkManager: https://searchfox.org/mozilla-central/search?q=ProfileBufferChunkManager.h&path=&case=true&regexp=false
 .. _ProfileBufferChunk: https://searchfox.org/mozilla-central/search?q=ProfileBufferChunk&path=&case=true&regexp=false
 .. _ProfileBufferChunkManagerWithLocalLimit: https://searchfox.org/mozilla-central/search?q=ProfileBufferChunkManagerWithLocalLimit&case=true&path=
-.. _ProfilerParent.h: https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerParent.h
-.. _ProfilerChild.h: https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerChild.h
-.. _ProfileBuffer.h: https://searchfox.org/firefox-main/source/tools/profiler/core/ProfileBuffer.h
+.. _ProfilerChild.h: :searchfox:`tools/profiler/public/ProfilerChild.h`
 .. _ProfileBuffer: https://searchfox.org/mozilla-central/search?q=ProfileBuffer&path=&case=true&regexp=false
 .. _ProfilerParent: https://searchfox.org/mozilla-central/search?q=ProfilerParent&path=&case=true&regexp=false
 .. _ProfilerChild: https://searchfox.org/mozilla-central/search?q=ProfilerChild&path=&case=true&regexp=false
diff --git a/tools/profiler/docs/code-overview.rst b/tools/profiler/docs/code-overview.rst
index 24de3440e689..53ccc655abab 100644
--- a/tools/profiler/docs/code-overview.rst
+++ b/tools/profiler/docs/code-overview.rst
@@ -162,70 +162,70 @@ Directories
 
 * Non-Profiler supporting code
 
-  * `mfbt <https://searchfox.org/firefox-main/source/mfbt>`_ - Mostly
+  * :searchfox:`mfbt` - Mostly
     replacements for C++ std library facilities.
 
-  * `mozglue/misc <https://searchfox.org/firefox-main/source/mozglue/misc>`_
+  * :searchfox:`mozglue/misc`
 
-    * `PlatformMutex.h <https://searchfox.org/firefox-main/source/mozglue/misc/PlatformMutex.h>`_ -
+    * :searchfox:`PlatformMutex.h <mozglue/misc/PlatformMutex.h>` -
       Mutex base classes.
-    * `StackWalk.h <https://searchfox.org/firefox-main/source/mozglue/misc/StackWalk.h>`_ -
+    * :searchfox:`StackWalk.h <mozglue/misc/StackWalk.h>` -
       Stack-walking functions.
-    * `TimeStamp.h <https://searchfox.org/firefox-main/source/mozglue/misc/TimeStamp.h>`_ -
+    * :searchfox:`TimeStamp.h <mozglue/misc/TimeStamp.h>` -
       Timestamps and time durations.
 
-  * `xpcom <https://searchfox.org/firefox-main/source/xpcom>`_
+  * :searchfox:`xpcom`
 
-    * `ds <https://searchfox.org/firefox-main/source/xpcom/ds>`_ -
+    * :searchfox:`ds <xpcom/ds>` -
       Data structures like arrays, strings.
 
-    * `threads <https://searchfox.org/firefox-main/source/xpcom/threads>`_ -
+    * :searchfox:`threads <xpcom/threads>` -
       Threading functions.
 
 * Profiler back-end
 
-  * `mozglue/baseprofiler <https://searchfox.org/firefox-main/source/mozglue/baseprofiler>`_ -
+  * :searchfox:`mozglue/baseprofiler` -
     Base Profiler code, usable from anywhere in Firefox. Because it lives in
     mozglue, it's loaded right at the beginning, so it's possible to start the
     profiler very early, even before Firefox loads its big&heavy "xul" library.
 
-    * `baseprofiler's public <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public>`_ -
+    * :searchfox:`baseprofiler's public <mozglue/baseprofiler/public>` -
       Public headers, may be #included from anywhere.
-    * `baseprofiler's core <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/core>`_ -
+    * :searchfox:`baseprofiler's core <mozglue/baseprofiler/core>` -
       Main implementation code.
-    * `baseprofiler's lul <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/lul>`_ -
+    * :searchfox:`baseprofiler's lul <mozglue/baseprofiler/lul>` -
       Special stack-walking code for Linux.
-    * `../tests/TestBaseProfiler.cpp <https://searchfox.org/firefox-main/source/mozglue/tests/TestBaseProfiler.cpp>`_ -
+    * :searchfox:`../tests/TestBaseProfiler.cpp <mozglue/tests/TestBaseProfiler.cpp>` -
       Unit tests.
 
-  * `tools/profiler <https://searchfox.org/firefox-main/source/tools/profiler>`_ -
+  * :searchfox:`tools/profiler` -
     Gecko Profiler code, only usable from the xul library. That library is
     loaded a short time after Firefox starts, so the Gecko Profiler is not able
     to profile the early phase of the application, Base Profiler handles that,
     and can pass its collected data to the Gecko Profiler when the latter
     starts.
 
-    * `public <https://searchfox.org/firefox-main/source/tools/profiler/public>`_ -
+    * :searchfox:`public <tools/profiler/public>` -
       Public headers, may be #included from most libxul code.
-    * `core <https://searchfox.org/firefox-main/source/tools/profiler/core>`_ -
+    * :searchfox:`core <tools/profiler/core>` -
       Main implementation code.
-    * `gecko <https://searchfox.org/firefox-main/source/tools/profiler/gecko>`_ -
+    * :searchfox:`gecko <tools/profiler/gecko>` -
       Control from JS, and multi-process/IPC code.
-    * `lul <https://searchfox.org/firefox-main/source/tools/profiler/lul>`_ -
+    * :searchfox:`lul <tools/profiler/lul>` -
       Special stack-walking code for Linux.
-    * `rust-api <https://searchfox.org/firefox-main/source/tools/profiler/rust-api>`_,
-      `rust-helper <https://searchfox.org/firefox-main/source/tools/profiler/rust-helper>`_
-    * `tests <https://searchfox.org/firefox-main/source/tools/profiler/tests>`_
+    * :searchfox:`rust-api <tools/profiler/rust-api>`,
+      :searchfox:`rust-helper <tools/profiler/rust-helper>`
+    * :searchfox:`tests <tools/profiler/tests>`
 
-  * `devtools/client/performance-new <https://searchfox.org/firefox-main/source/devtools/client/performance-new>`_,
-    `devtools/shared/performance-new <https://searchfox.org/firefox-main/source/devtools/shared/performance-new>`_ -
+  * :searchfox:`devtools/client/performance-new`,
+    :searchfox:`devtools/shared/performance-new` -
     Middleware code for about:profiling and devtools panel functionality.
 
   * js, starting with
-    `js/src/vm/GeckoProfiler.h <https://searchfox.org/firefox-main/source/js/src/vm/GeckoProfiler.h>`_ -
+    :searchfox:`js/src/vm/GeckoProfiler.h` -
     JavaScript engine support, mostly to capture JS stacks.
 
-  * `toolkit/components/extensions/schemas/geckoProfiler.json <https://searchfox.org/firefox-main/source/toolkit/components/extensions/schemas/geckoProfiler.json>`_ -
+  * :searchfox:`toolkit/components/extensions/schemas/geckoProfiler.json` -
     File that needs to be updated when Profiler features change.
 
 * Profiler front-end
@@ -240,7 +240,7 @@ Headers
 *******
 
 The most central public header is
-`GeckoProfiler.h <https://searchfox.org/firefox-main/source/tools/profiler/public/GeckoProfiler.h>`_,
+:searchfox:`GeckoProfiler.h <tools/profiler/public/GeckoProfiler.h>`,
 from which almost everything else can be found, it can be a good starting point
 for exploration.
 It includes other headers, which together contain important top-level macros and
@@ -320,7 +320,7 @@ Locking
 =======
 The locking primitives in PlatformMutex.h are not supposed to be used as-is, but
 through a user-accessible implementation. For the Profilers, this is in
-`BaseProfilerDetail.h <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/BaseProfilerDetail.h>`_.
+:searchfox:`BaseProfilerDetail.h <mozglue/baseprofiler/public/BaseProfilerDetail.h>`.
 
 In addition to the usual ``Lock``, ``TryLock``, and ``Unlock`` functions,
 `BaseProfilerMutex <https://searchfox.org/mozilla-central/search?q=BaseProfilerMutex>`_
@@ -449,7 +449,7 @@ information under ProfilerThreadRegistrationData below).
 ThreadRegistrationData and accessors
 ====================================
 
-`The ProfilerThreadRegistrationData.h header <https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerThreadRegistrationData.h>`_
+:searchfox:`The ProfilerThreadRegistrationData.h header <tools/profiler/public/ProfilerThreadRegistrationData.h>`
 contains a hierarchy of classes that encapsulate all the thread-related data.
 
 ``ThreadRegistrationData`` contains all the actual data members, including:
@@ -513,7 +513,7 @@ ProfilerThreadState.h functions
 ===============================
 
 The
-`ProfilerThreadState.h <https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerThreadState.h>`_
+:searchfox:`ProfilerThreadState.h <tools/profiler/public/ProfilerThreadState.h>`
 header provides a few helpful functions related to threads, including:
 
 * ``profiler_is_active_and_thread_is_registered``
@@ -608,7 +608,7 @@ The following sessions give more technical details.
 leb128iterator.h
 ================
 
-`This utility header <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/leb128iterator.h>`_
+:searchfox:`This utility header <mozglue/baseprofiler/public/leb128iterator.h>`
 contains some functions to read and write unsigned "LEB128" numbers
 (`LEB128 on wikipedia <https://en.wikipedia.org/wiki/LEB128>`_).
 
@@ -752,7 +752,7 @@ uses a ``ProfileChunkedBuffer`` to store data, and handles the different kinds
 of entries that the Profilers want to read/write.
 
 Each entry starts with a tag identifying a kind. These kinds can be found in
-`ProfileBufferEntryKinds.h <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/ProfileBufferEntryKinds.h>`_.
+:searchfox:`ProfileBufferEntryKinds.h <mozglue/baseprofiler/public/ProfileBufferEntryKinds.h>`.
 
 There are "legacy" kinds, which are small fixed-length entries, such as:
 Categories, labels, frame information, counters, etc. These can be stored in
@@ -960,7 +960,7 @@ parameter, and also a pointer to the function that can capture the stack
 latter one knows about JS).
 
 From here, we enter the land of
-`BaseProfilerMarkersDetail.h <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/BaseProfilerMarkersDetail.h>`_,
+:searchfox:`BaseProfilerMarkersDetail.h <mozglue/baseprofiler/public/BaseProfilerMarkersDetail.h>`,
 which employs some heavy template techniques, in order to most efficiently
 serialize the given marker payload arguments, in order to make them
 deserializable when outputting the final JSON. In previous implementations, for
@@ -1021,7 +1021,7 @@ Deconstructing this mouthful of an template:
   variadic function to write all the marker data, that is:
 
   * The entry kind that must be at the beginning of every buffer entry, in this
-    case `ProfileBufferEntryKind::Marker <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/ProfileBufferEntryKinds.h#78>`_.
+    case :searchfox:`ProfileBufferEntryKind::Marker <mozglue/baseprofiler/public/ProfileBufferEntryKinds.h#78>`.
   * The common marker data (options first, name, category, deserialization tag).
   * Then all the marker-type-specific arguments. Note that the C++ types
     are those extracted from the deserialization function, so we know that
@@ -1044,7 +1044,7 @@ See https://firefox-source-docs.mozilla.org/tools/profiler/instrumenting-javascr
 Adding Markers from Java
 ========================
 
-See https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/ProfilerController.java
+See :searchfox:`mobile/android/geckoview/src/main/java/org/mozilla/geckoview/ProfilerController.java`
 
 *************
 Profiling Log
@@ -1337,12 +1337,12 @@ IPC (Inter-Process Communication)
 See https://firefox-source-docs.mozilla.org/ipc/.
 
 As a quick summary, some message-passing function-like declarations live in
-`PProfiler.ipdl <https://searchfox.org/firefox-main/source/tools/profiler/gecko/PProfiler.ipdl>`_,
+:searchfox:`PProfiler.ipdl <tools/profiler/gecko/PProfiler.ipdl>`,
 and corresponding ``SendX`` and ``RecvX`` C++ functions are respectively
 generated in
-`PProfilerParent.h <https://searchfox.org/firefox-main/source/__GENERATED__/ipc/ipdl/_ipdlheaders/mozilla/PProfilerParent.h>`_,
+:searchfox:`PProfilerParent.h <__GENERATED__/ipc/ipdl/_ipdlheaders/mozilla/PProfilerParent.h>`,
 and virtually declared (for user implementation) in
-`PProfilerChild.h <https://searchfox.org/firefox-main/source/__GENERATED__/ipc/ipdl/_ipdlheaders/mozilla/PProfilerChild.h>`_.
+:searchfox:`PProfilerChild.h <__GENERATED__/ipc/ipdl/_ipdlheaders/mozilla/PProfilerChild.h>`.
 
 During Profiling
 ================
@@ -1353,7 +1353,7 @@ Exit profiles
 One IPC message that is not in PProfiler.ipdl, is
 `ShutdownProfile <https://searchfox.org/mozilla-central/search?q=ShutdownProfile%28&path=&case=false&regexp=false>`_
 in
-`PContent.ipdl <https://searchfox.org/firefox-main/source/dom/ipc/PContent.ipdl>`_.
+:searchfox:`PContent.ipdl <dom/ipc/PContent.ipdl>`.
 
 It's called from
 `ContentChild::ShutdownInternal <https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla3dom12ContentChild16ShutdownInternalEv>`_,
diff --git a/tools/profiler/docs/instrumenting-android.rst b/tools/profiler/docs/instrumenting-android.rst
index f9663378ac13..0328a4a5a982 100644
--- a/tools/profiler/docs/instrumenting-android.rst
+++ b/tools/profiler/docs/instrumenting-android.rst
@@ -20,7 +20,7 @@ Markers in the GeckoView Java codebase
 **************************************
 
 If you are in the GeckoView codebase, then you should have access to ``ProfilerController``.
-See the `ProfilerController Java file`_ (`javadoc`_) to find which methods you can use to
+See the :searchfox:`ProfilerController Java file <mobile/android/geckoview/src/main/java/org/mozilla/geckoview/ProfilerController.java>` (`javadoc`_) to find which methods you can use to
 instrument your source code.
 
 Here's an example:
@@ -60,8 +60,8 @@ Markers in the Fenix codebase
 *****************************
 
 If you are in the Fenix codebase, then you should have access to the Android
-components. The Android components includes a `Profiler interface here`_, with
-its corresponding `implementation here`_. You should be able to do everything
+components. The Android components includes a :searchfox:`Profiler interface here <mobile/android/android-components/components/concept/base/src/main/java/mozilla/components/concept/base/profiler/Profiler.kt>`, with
+its corresponding :searchfox:`implementation here <mobile/android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/profiler/Profiler.kt>`. You should be able to do everything
 you can do with the ``ProfilerController``. Here's an example on how to call them:
 
 .. code-block:: kotlin
@@ -95,7 +95,4 @@ profiler is active. Here's an example:
     components.core.engine.profiler?.addMarker("Marker Name", info)
   }
 
-.. _ProfilerController Java file: https://searchfox.org/firefox-main/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/ProfilerController.java
 .. _javadoc: https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/ProfilerController.html
-.. _Profiler interface here: https://searchfox.org/firefox-main/source/mobile/android/android-components/components/concept/base/src/main/java/mozilla/components/concept/base/profiler/Profiler.kt
-.. _implementation here: https://searchfox.org/firefox-main/source/mobile/android/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/profiler/Profiler.kt
diff --git a/tools/profiler/docs/instrumenting-rust.rst b/tools/profiler/docs/instrumenting-rust.rst
index 05d8f519da20..70320d6331a9 100644
--- a/tools/profiler/docs/instrumenting-rust.rst
+++ b/tools/profiler/docs/instrumenting-rust.rst
@@ -114,7 +114,7 @@ Adding a stack frame label:
         bar
     }
 
-See the list of all profiling categories in the `profiling_categories.yaml`_ file.
+See the list of all profiling categories in the :searchfox:`profiling_categories.yaml <mozglue/baseprofiler/build/profiling_categories.yaml>` file.
 
 Adding Markers
 --------------
@@ -232,8 +232,8 @@ Name, category, options.
 1. Marker name
     The first argument is the name of this marker. This will be displayed in most places
     the marker is shown. It can be a literal string, or any dynamic string.
-2. `Profiling category pair`_
-    A category + subcategory pair from the `the list of categories`_.
+2. :searchfox:`Profiling category pair <__GENERATED__/tools/profiler/rust-api/src/gecko_bindings/profiling_categories.rs>`
+    A category + subcategory pair from the :searchfox:`the list of categories <mozglue/baseprofiler/build/profiling_categories.yaml>`.
     ``gecko_profiler_category!`` macro should be used to create a profiling category
     pair since it's easier to use, e.g. ``gecko_profiler_category!(JavaScript, Parsing)``.
     Second parameter can be omitted to use the default subcategory directly.
@@ -425,9 +425,6 @@ needs to be implemented:
 
     :ref:`See the C++ markers guide for more details about it <marker-type-display-schema>`.
 
-.. _profiling_categories.yaml: https://searchfox.org/firefox-main/source/mozglue/baseprofiler/build/profiling_categories.yaml
-.. _Profiling category pair: https://searchfox.org/firefox-main/source/__GENERATED__/tools/profiler/rust-api/src/gecko_bindings/profiling_categories.rs
-.. _the list of categories: https://searchfox.org/firefox-main/source/mozglue/baseprofiler/build/profiling_categories.yaml
 .. _MarkerOptions: https://searchfox.org/mozilla-central/define?q=rust_analyzer::cargo::gecko_profiler::0_1_0::options::marker::MarkerOptions
 .. _MarkerTiming: https://searchfox.org/mozilla-central/define?q=rust_analyzer::cargo::gecko_profiler::0_1_0::options::marker::MarkerTiming
 .. _MarkerStack: https://searchfox.org/mozilla-central/define?q=rust_analyzer::cargo::gecko_profiler::0_1_0::options::marker::[MarkerStack]
diff --git a/tools/profiler/docs/markers-guide.rst b/tools/profiler/docs/markers-guide.rst
index bea84ebdba9a..bcdfa73b2d4e 100644
--- a/tools/profiler/docs/markers-guide.rst
+++ b/tools/profiler/docs/markers-guide.rst
@@ -119,14 +119,14 @@ Header to Include
 ^^^^^^^^^^^^^^^^^
 
 If the compilation unit only defines and records untyped, text, and/or its own markers, include
-`the main profiler markers header <https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerMarkers.h>`_:
+:searchfox:`the main profiler markers header <tools/profiler/public/ProfilerMarkers.h>`:
 
 .. code-block:: cpp
 
     #include "mozilla/ProfilerMarkers.h"
 
 If it also records one of the other common markers defined in
-`ProfilerMarkerTypes.h <https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerMarkerTypes.h>`_,
+:searchfox:`ProfilerMarkerTypes.h <tools/profiler/public/ProfilerMarkerTypes.h>`,
 include that one instead:
 
 .. code-block:: cpp
@@ -134,7 +134,7 @@ include that one instead:
     #include "mozilla/ProfilerMarkerTypes.h"
 
 And if it uses any other profiler functions (e.g., labels), use
-`the main Gecko Profiler header <https://searchfox.org/firefox-main/source/tools/profiler/public/GeckoProfiler.h>`_
+:searchfox:`the main Gecko Profiler header <tools/profiler/public/GeckoProfiler.h>`
 instead:
 
 .. code-block:: cpp
@@ -171,8 +171,8 @@ Name, category, options.
 1. Marker name
     The first argument is the name of this marker. This will be displayed in most places
     the marker is shown. It can be a literal C string, or any dynamic string object.
-2. `Category pair name <https://searchfox.org/firefox-main/source/__GENERATED__/mozglue/baseprofiler/public/ProfilingCategoryList.h>`_
-    Choose a category + subcategory from the `the list of categories <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/build/profiling_categories.yaml>`_.
+2. :searchfox:`Category pair name <__GENERATED__/mozglue/baseprofiler/public/ProfilingCategoryList.h>`
+    Choose a category + subcategory from the :searchfox:`the list of categories <mozglue/baseprofiler/build/profiling_categories.yaml>`.
     This is the second parameter of each ``SUBCATEGORY`` line, for instance ``LAYOUT_Reflow``.
     (Internally, this is really a `MarkerCategory <https://searchfox.org/mozilla-central/define?q=T_mozilla%3A%3AMarkerCategory>`_
     object, in case you need to construct it elsewhere.)
@@ -287,8 +287,8 @@ events.
 
 If there’s not an obvious pointer that matches the lifetime of the flow, there are alternatives:
 
-- `Flow::ProcessScoped(uint64_t aFlowId) <https://searchfox.org/mozilla-central/rev/86878e73a24fe32ea09dbae5b55362efaf7485c8/mozglue/baseprofiler/public/Flow.h#43>`__ -- the id should be unique in the process
-- `Flow::Global(uint64_t aFlowId) <https://searchfox.org/mozilla-central/rev/86878e73a24fe32ea09dbae5b55362efaf7485c8/mozglue/baseprofiler/public/Flow.h#58>`__ -- the id should be unique across all processes
+- :searchfox:`Flow::ProcessScoped(uint64_t aFlowId) <mozilla-central/rev/86878e73a24fe32ea09dbae5b55362efaf7485c8:mozglue/baseprofiler/public/Flow.h#43>` -- the id should be unique in the process
+- :searchfox:`Flow::Global(uint64_t aFlowId) <mozilla-central/rev/86878e73a24fe32ea09dbae5b55362efaf7485c8:mozglue/baseprofiler/public/Flow.h#58>` -- the id should be unique across all processes
 
 ``Runnable``, IPC, and ``Task`` have already been annotated with flow markers.
 This allow linking flows together, even across process boundaries.
@@ -411,10 +411,10 @@ The first step is to determine the location of the marker type definition:
 
   * If there is no dependency on XUL, it can be defined in the Base Profiler, which can
     be used in most locations in the codebase:
-    `mozglue/baseprofiler/public/BaseProfilerMarkerTypes.h <https://searchfox.org/firefox-main/source/mozglue/baseprofiler/public/BaseProfilerMarkerTypes.h>`__
+    :searchfox:`mozglue/baseprofiler/public/BaseProfilerMarkerTypes.h`
 
   * However, if there is a XUL dependency, then it needs to be defined in the Gecko Profiler:
-    `tools/profiler/public/ProfilerMarkerTypes.h <https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerMarkerTypes.h>`__
+    :searchfox:`tools/profiler/public/ProfilerMarkerTypes.h`
 
 .. _how-to-define-new-marker-types:
 
diff --git a/tools/profiler/docs/memory.rst b/tools/profiler/docs/memory.rst
index 1f99e4717f96..314abee7a7ba 100644
--- a/tools/profiler/docs/memory.rst
+++ b/tools/profiler/docs/memory.rst
@@ -10,8 +10,7 @@ enabling the "Native Allocations" checkbox. It is only available in Nightly, as
 uses a technique of hooking into malloc that could be a little more risky to apply to
 the broader population of Firefox users.
 
-This implementation is located in: `tools/profiler/core/memory_hooks.cpp
-<https://searchfox.org/firefox-main/source/tools/profiler/core/memory_hooks.cpp>`_
+This implementation is located in: :searchfox:`tools/profiler/core/memory_hooks.cpp`
 
 It works by hooking into all of the malloc calls. When the profiler is running, it
 performs a `Bernoulli trial`_ that will pass for a given probability of per-byte
@@ -37,10 +36,9 @@ memory is being allocated and deallocated during the profiling session.
 
 This information is then visualized in the `Firefox Profiler memory track`_.
 
-This feature uses the `Profiler Counters`_, which can be used to create other types
+This feature uses the :searchfox:`Profiler Counters <tools/profiler/public/ProfilerCounts.h>`, which can be used to create other types
 of cheap counting instrumentation.
 
 .. _Bernoulli trial: https://en.wikipedia.org/wiki/Bernoulli_trial
 .. _Firefox Profiler docs: https://profiler.firefox.com/docs/#/./memory-allocations
 .. _Firefox Profiler memory track: https://profiler.firefox.com/docs/#/./memory-allocations?id=memory-track
-.. _Profiler Counters: https://searchfox.org/firefox-main/source/tools/profiler/public/ProfilerCounts.h
diff --git a/tools/sanitizer/docs/tsan.rst b/tools/sanitizer/docs/tsan.rst
index 697a2fc00430..461efdf51ad6 100644
--- a/tools/sanitizer/docs/tsan.rst
+++ b/tools/sanitizer/docs/tsan.rst
@@ -230,7 +230,7 @@ silence a race while a fix is developed as well as to permanently silence a
        and think twice before attempting to suppress a race.
 
 The runtime Suppression list is directly baked into Firefox at compile-time and
-located at `build/sanitizers/TsanOptions.cpp <https://searchfox.org/firefox-main/source/build/sanitizers/TsanOptions.cpp>`__.
+located at :searchfox:`build/sanitizers/TsanOptions.cpp`.
 
 .. warning::
        **Important**: When adding a suppression, always make sure to include
diff --git a/tools/tryselect/docs/presets.rst b/tools/tryselect/docs/presets.rst
index 6ad349a1e223..87a5371baa62 100644
--- a/tools/tryselect/docs/presets.rst
+++ b/tools/tryselect/docs/presets.rst
@@ -55,7 +55,7 @@ Presets defined here are your own personal collection of presets. You can modify
 Shared Presets
 ~~~~~~~~~~~~~~
 
-You can also check presets into mozilla-central in `tools/tryselect/try_presets.yml`_. These presets
+You can also check presets into mozilla-central in :searchfox:`tools/tryselect/try_presets.yml`. These presets
 will be available to all users of ``mach try``, so please be mindful when editing this file. Make
 sure the name of the preset is scoped appropriately (i.e doesn't contain any team or module specific
 terminology). It is good practice to prefix the preset name with the name of the team or module that
@@ -81,5 +81,3 @@ The ``selector`` key (required) allows ``mach try`` to determine which subcomman
 The ``description`` key (optional in user presets but required for shared presets) is a human
 readable string describing what the preset selects and when to use it. All other values in the
 preset are forwarded to the specified selector as is.
-
-.. _tools/tryselect/try_presets.yml: https://searchfox.org/firefox-main/source/tools/tryselect/try_presets.yml
diff --git a/tools/update-verify/docs/index.rst b/tools/update-verify/docs/index.rst
index 55ee43330d31..a36e33f8f7c5 100644
--- a/tools/update-verify/docs/index.rst
+++ b/tools/update-verify/docs/index.rst
@@ -14,9 +14,9 @@ Both Balrog and the Linux updater binary are currently used as part of running u
 ------------
 How it works
 ------------
-At a high level, update verify simulates what happens when an update MAR is applied on a user machine. The result of that is compared against the full installer for the same version. If there are any differences (aside from a `small set of expected and known OK ones <https://searchfox.org/firefox-main/source/tools/update-verify/release/compare-directories.py#25-99>`__), the test fails.
+At a high level, update verify simulates what happens when an update MAR is applied on a user machine. The result of that is compared against the full installer for the same version. If there are any differences (aside from a :searchfox:`small set of expected and known OK ones <tools/update-verify/release/compare-directories.py#25-99>`), the test fails.
 
-This test is run for all older builds (back to the `last watershed update <https://searchfox.org/firefox-main/source/taskcluster/kinds/release-update-verify-config/kind.yml#53-59>`__ on all platforms. This means that we apply the same MARs over and over again, to different older versions of Firefox.
+This test is run for all older builds (back to the :searchfox:`last watershed update <taskcluster/kinds/release-update-verify-config/kind.yml#53-59>` on all platforms. This means that we apply the same MARs over and over again, to different older versions of Firefox.
 
 All tests are performed on Linux, with the `updater` from the older version's Linux package. For example, when testing 128.0 -> 129.0 mac updates, we will apply a 129.0 MAR to a 128.0 mac build with the 128.0 Linux updater binary.
 
@@ -28,4 +28,4 @@ With these details in mind, this is what the process looks like for testing a 12
 * Download the 129.0 en-US macOS complete MAR
 * Run the `updater` binary from the unpacked Linux build to apply it to the `source` directory
 * Diff the `source` and `target` directories
-* Compare the result against `expected differences <https://searchfox.org/firefox-main/source/tools/update-verify/release/compare-directories.py#25-99>`__ to determine pass or fail
+* Compare the result against :searchfox:`expected differences <tools/update-verify/release/compare-directories.py#25-99>` to determine pass or fail
diff --git a/uriloader/docs/uriloader.rst b/uriloader/docs/uriloader.rst
index 77eb43f88060..b36e66116509 100644
--- a/uriloader/docs/uriloader.rst
+++ b/uriloader/docs/uriloader.rst
@@ -22,7 +22,7 @@ other than the caller. It uses a few criteria to decide this including:
 
 Part of this handling may include running the content through a registered stream
 converter to convert the content type from one to another. This is done through
-the `stream converter service <https://searchfox.org/firefox-main/source/netwerk/streamconv>`_.
+the :searchfox:`stream converter service <netwerk/streamconv>`.
 When this happens a new ``nsDocumentOpenInfo`` is created to handle the new content
 in the same way as the current content.
 
@@ -43,4 +43,4 @@ flags passed to the loader service):
 
 For the most part the process ends at step 1 because nsDocShell passes a ``nsDSURIContentListener``
 for the ``nsIURIContentListener`` consulted first and it accepts most of the
-`web content types <https://searchfox.org/firefox-main/source/layout/build/components.conf>`_.
+:searchfox:`web content types <layout/build/components.conf>`.
diff --git a/widget/windows/docs/blocklist.rst b/widget/windows/docs/blocklist.rst
index 4410c76d96da..34b24a1fe2e5 100644
--- a/widget/windows/docs/blocklist.rst
+++ b/widget/windows/docs/blocklist.rst
@@ -73,7 +73,7 @@ How to request to block a DLL
 -----------------------------
 
 Our codebase has the file named
-`WindowsDllBlocklistDefs.in <https://searchfox.org/firefox-main/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklistDefs.in>`_ from which our build process generates DLL blocklists as C++ header files and compiles them. To block a new DLL, you create a patch to update WindowsDllBlocklistDefs.in and land it on our codebase, following our standard development process. Moreover, you need to fill out a form specific to the DLL blockling request so that reviewers can review the impact and risk as well as the patch itself.
+:searchfox:`WindowsDllBlocklistDefs.in <toolkit/xre/dllservices/mozglue/WindowsDllBlocklistDefs.in>` from which our build process generates DLL blocklists as C++ header files and compiles them. To block a new DLL, you create a patch to update WindowsDllBlocklistDefs.in and land it on our codebase, following our standard development process. Moreover, you need to fill out a form specific to the DLL blockling request so that reviewers can review the impact and risk as well as the patch itself.
 
 Here are the steps:
 
@@ -274,8 +274,7 @@ initialized very early during browser startup. If the :ref:`launcher process
   - This is so (ideally) no DLLs can be injected before the blocklist is set up.
 
 If the launcher process is not available, a different blocklist is used, defined
-in `mozglue/WindowsDllBlocklist.cpp
-<https://searchfox.org/firefox-main/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp>`_.
+in :searchfox:`mozglue/WindowsDllBlocklist.cpp <toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp>`.
 This code does not currently support the dynamic blocklist. This is intended to
 only be used in testing and other non-deployed scenarios, so this shouldn't be
 a problem for users.
@@ -294,8 +293,7 @@ app data directory, specifically
 
 ``<Roaming AppData directory>\Mozilla\Firefox\blocklist-<install hash>``
 
-Note that the install hash here is what is returned by `GetInstallHash()
-<https://searchfox.org/firefox-main/source/toolkit/mozapps/update/common/commonupdatedir.cpp#404>`_,
+Note that the install hash here is what is returned by :searchfox:`GetInstallHash() <toolkit/mozapps/update/common/commonupdatedir.cpp#404>`,
 and is suitable for uniquely identifying the particular Firefox installation
 that is running.
 
@@ -303,8 +301,7 @@ On first launch, this location will be written to the registry, and can be
 overriden by setting that key to a different file location. The registry key is
 ``HKEY_CURRENT_USER\Software\Mozilla\Firefox\Launcher``, and the name is the
 full path to firefox.exe with "\|Blocklist" appended. This code is in
-`LauncherRegistryInfo
-<https://searchfox.org/firefox-main/source/toolkit/xre/LauncherRegistryInfo.cpp>`_.
+:searchfox:`LauncherRegistryInfo <toolkit/xre/LauncherRegistryInfo.cpp>`.
 
 Adding to and removing from the dynamic blocklist
 -------------------------------------------------
diff --git a/widget/windows/docs/windows-pointing-device/index.rst b/widget/windows/docs/windows-pointing-device/index.rst
index 2f22495e16e5..48c321ad1c70 100644
--- a/widget/windows/docs/windows-pointing-device/index.rst
+++ b/widget/windows/docs/windows-pointing-device/index.rst
@@ -568,7 +568,7 @@ Windows and the Web Platform:
 
 
     Firefox does not appear to have ever used these APIs to allow tablet pen
-    input, with the exception of `one piece of code <https://searchfox.org/mozilla-central/rev/e6cb503ac22402421186e7488d4250cc1c5fecab/widget/windows/InkCollector.cpp>`__
+    input, with the exception of :searchfox:`one piece of code <mozilla-central/rev/e6cb503ac22402421186e7488d4250cc1c5fecab:widget/windows/InkCollector.cpp>`
     to detect when the pen leaves the Firefox window to solve
     `Bug 1016232 <https://bugzilla.mozilla.org/show_bug.cgi?id=1016232>`__.
 
diff --git a/xpcom/docs/collections.rst b/xpcom/docs/collections.rst
index 670215bfac94..64c0f2941346 100644
--- a/xpcom/docs/collections.rst
+++ b/xpcom/docs/collections.rst
@@ -81,7 +81,7 @@ Class Reference
     around ``nsBaseHashtable``. See the methods defined on that class for
     more detailed documentation.
 
-    https://searchfox.org/firefox-main/source/xpcom/ds/nsBaseHashtable.h
+    :searchfox:`xpcom/ds/nsBaseHashtable.h`
 
     .. cpp:function:: uint32_t Count() const
 
@@ -111,4 +111,4 @@ Class Reference
     around ``nsTBaseHashSet``. See the methods defined on that class for
     more detailed documentation.
 
-    https://searchfox.org/firefox-main/source/xpcom/ds/nsTHashSet.h
+    :searchfox:`xpcom/ds/nsTHashSet.h`
diff --git a/xpcom/docs/hashtables.rst b/xpcom/docs/hashtables.rst
index aa68b1ffd25d..98403734794f 100644
--- a/xpcom/docs/hashtables.rst
+++ b/xpcom/docs/hashtables.rst
@@ -95,9 +95,8 @@ If there is a key type, you should use an ``nsTHashMap``.
 ``nsTHashMap`` is a template with two parameters. The first is the hash key
 and the second is the data to be stored as the value in the map. Most of
 the time, you can simply pass the raw key type as the first parameter,
-so long as its supported by `nsTHashMap.h <https://searchfox.org/firefox-main/source/xpcom/ds/nsTHashMap.h>`_.
-It is also possible to specify custom keys if necessary. See `nsHashKeys.h
-<https://searchfox.org/firefox-main/source/xpcom/ds/nsHashKeys.h>`_ for examples.
+so long as its supported by :searchfox:`nsTHashMap.h <xpcom/ds/nsTHashMap.h>`.
+It is also possible to specify custom keys if necessary. See :searchfox:`nsHashKeys.h <xpcom/ds/nsHashKeys.h>` for examples.
 
 There are a number of more esoteric hashkey classes in nsHashKeys.h, and
 you can always roll your own if none of these fit your needs (make sure
@@ -124,7 +123,7 @@ Hashtable API
 The hashtable classes all expose the same basic API. There are three
 key methods, ``Get``, ``InsertOrUpdate``, and ``Remove``, which retrieve entries from the
 hashtable, write entries into the hashtable, and remove entries from the
-hashtable respectively. See `nsBaseHashtable.h <https://searchfox.org/firefox-main/source/xpcom/ds/nsBaseHashtable.h>`_
+hashtable respectively. See :searchfox:`nsBaseHashtable.h <xpcom/ds/nsBaseHashtable.h>`
 for more details.
 
 The hashtables that hold references to pointers (nsRefPtrHashtable and
diff --git a/xpcom/docs/hashtables_detailed.rst b/xpcom/docs/hashtables_detailed.rst
index 9a579c0f5f65..a5f2e1fde409 100644
--- a/xpcom/docs/hashtables_detailed.rst
+++ b/xpcom/docs/hashtables_detailed.rst
@@ -34,8 +34,7 @@ and tuned, and hide the inner complexities of hashtable implementations:
 PLHashTable
 ~~~~~~~~~~~
 
-``PLHashTable`` is a part of NSPR. The header file can be found at `plhash.h
-<https://searchfox.org/firefox-main/source/nsprpub/lib/ds/plhash.h>`_.
+``PLHashTable`` is a part of NSPR. The header file can be found at :searchfox:`plhash.h <nsprpub/lib/ds/plhash.h>`.
 
 There are two situations where ``PLHashTable`` may be preferable:
 
@@ -52,8 +51,7 @@ To use ``nsTHashtable``, you must declare an entry-class. This
 entry class contains the key and the data that you are hashing. It also
 declares functions that manipulate the key. In most cases, the functions
 of this entry class can be entirely inline. For examples of entry classes,
-see the declarations at `nsHashKeys.h
-<https://searchfox.org/firefox-main/source/xpcom/ds/nsHashKeys.h>`_.
+see the declarations at :searchfox:`nsHashKeys.h <xpcom/ds/nsHashKeys.h>`.
 
 The template parameter is the entry class. After construction, use the
 functions ``PutEntry/GetEntry/RemoveEntry`` to alter the hashtable. The
@@ -93,8 +91,7 @@ provide the following features:
 
 ``nsBaseHashtable`` is not used directly; choose one of the three
 derivative classes based on the data type you want to store. The
-``KeyClass`` is taken from `nsHashKeys.h
-<https://searchfox.org/firefox-main/source/xpcom/ds/nsHashKeys.h>`_ and is the same for all
+``KeyClass`` is taken from :searchfox:`nsHashKeys.h <xpcom/ds/nsHashKeys.h>` and is the same for all
 three classes:
 
 -  ``nsTHashMap<KeyClass, DataType>`` - ``DataType`` is a simple
@@ -106,9 +103,9 @@ three classes:
    when the entry is removed.
 
 The important files to read are
-`nsBaseHashtable.h <https://searchfox.org/firefox-main/source/xpcom/ds/nsBaseHashtable.h>`_
+:searchfox:`nsBaseHashtable.h <xpcom/ds/nsBaseHashtable.h>`
 and
-`nsHashKeys.h <https://searchfox.org/firefox-main/source/xpcom/ds/nsHashKeys.h>`_.
+:searchfox:`nsHashKeys.h <xpcom/ds/nsHashKeys.h>`.
 These classes can be used on the stack, as a class member, or on the heap.
 
 .. _Using_nsTHashtable_as_a_hash-set:
diff --git a/xpcom/docs/mozpromise.rst b/xpcom/docs/mozpromise.rst
index 2ed1044a0f8c..b0039970327a 100644
--- a/xpcom/docs/mozpromise.rst
+++ b/xpcom/docs/mozpromise.rst
@@ -25,7 +25,7 @@ safety, and maintaining the correct sequence of operations in complex
 applications, in contrast to the usual pattern seen in the Gecko code base,
 which is dispatching ``Runnable`` manually.
 
-Another option for syncing state across threads is to use `State Mirroring <https://searchfox.org/firefox-main/source/xpcom/threads/StateMirroring.h>`_.
+Another option for syncing state across threads is to use :searchfox:`State Mirroring <xpcom/threads/StateMirroring.h>`.
 
 ``MozPromise`` aren't really related to the DOM ``Promise`` class, but can be often used in
 conjunction. This is done manually by for example calling
@@ -315,7 +315,7 @@ Disconnecting a request **must** happen on the target thread of the resolve/reje
 handler it is tracking. This handler is released when ``Disconnect()`` is called.
 
 When dealing with ``MozPromise`` close to the WebIDL binding layer,
-another option is `DOMMozPromiseRequestHolder <https://searchfox.org/firefox-main/source/dom/base/DOMMozPromiseRequestHolder.h>`_,
+another option is :searchfox:`DOMMozPromiseRequestHolder <dom/base/DOMMozPromiseRequestHolder.h>`,
 that will disconnect promises appropriately when the global goes away.
 It works in the same way otherwise.
 
@@ -413,7 +413,7 @@ Advanced features
 Direct Task Dispatch
 --------------------
 
-`Direct task dispatch <https://searchfox.org/firefox-main/source/xpcom/threads/nsIDirectTaskDispatcher.idl>`_
+:searchfox:`Direct task dispatch <xpcom/threads/nsIDirectTaskDispatcher.idl>`
 is a feature in ``MozPromise`` that allows the resolve or
 reject callbacks to be executed on the direct task queue instead of the normal
 event loop. This is particularly useful for scenarios where multiple
@@ -433,7 +433,7 @@ To enable direct task dispatch, the ``UseDirectTaskDispatch`` method is called
 on the ``MozPromiseHolder`` instance. This method sets the promise to use the
 direct event queue for dispatching the resolve or reject callbacks.
 
-A related concept is `"tail dispatching" <https://searchfox.org/mozilla-central/rev/9fa446ad77af13847a7da250135fc58b1a1bd5b9/xpcom/threads/AbstractThread.h#72-76>`_
+A related concept is :searchfox:`"tail dispatching" <mozilla-central/rev/9fa446ad77af13847a7da250135fc58b1a1bd5b9:xpcom/threads/AbstractThread.h#72-76>`
 of ``Runnable``.
 
 Synchronous Dispatch
diff --git a/xpcom/docs/stringguide.rst b/xpcom/docs/stringguide.rst
index 13d094a47c93..cf89fdbf6f2e 100644
--- a/xpcom/docs/stringguide.rst
+++ b/xpcom/docs/stringguide.rst
@@ -11,8 +11,7 @@ Introduction
 
 The string classes are a library of C++ classes which are used to manage
 buffers of wide (16-bit) and narrow (8-bit) character strings. The headers
-and implementation are in the `xpcom/string
-<https://searchfox.org/firefox-main/source/xpcom/string>`_ directory. All
+and implementation are in the :searchfox:`xpcom/string` directory. All
 strings are stored as a single contiguous buffer of characters.
 
 The 8-bit and 16-bit string classes have completely separate base classes,
@@ -467,8 +466,7 @@ common encodings are:
 In addition, there exist multiple other (legacy) encodings. The Web-relevant
 ones are defined in the `Encoding Standard <https://encoding.spec.whatwg.org/>`_.
 Conversions from these encodings to
-UTF-8 and UTF-16 are provided by `mozilla::Encoding
-<https://searchfox.org/firefox-main/source/intl/Encoding.h#109>`_.
+UTF-8 and UTF-16 are provided by :searchfox:`mozilla::Encoding <intl/Encoding.h#109>`.
 Additionally, on Windows the are some rare cases (e.g. drag&drop) where it's
 necessary to call a system API with data encoded in the Windows
 locale-dependent legacy encoding instead of UTF-16. In those rare cases, use
diff --git a/xpcom/docs/writing-xpcom-interface.rst b/xpcom/docs/writing-xpcom-interface.rst
index 8e38a2b41283..afd4a62d0fef 100644
--- a/xpcom/docs/writing-xpcom-interface.rst
+++ b/xpcom/docs/writing-xpcom-interface.rst
@@ -8,11 +8,7 @@ High Level Overview
 
 In order to write code that works in native code (C++, Rust), and JavaScript contexts, it's necessary to have a mechanism to do so. For chrome privileged contexts, this is the XPCOM Interface Class.
 
-This mechanism starts with an :ref:`XPIDL` file to define the shape of the interface. In the `build system`_, this file is processed, and `Rust`_ and `C++`_ code is automatically generated.
-
-.. _build system: https://searchfox.org/firefox-main/source/xpcom/idl-parser/xpidl
-.. _Rust: https://searchfox.org/firefox-main/source/__GENERATED__/dist/xpcrs/rt
-.. _C++: https://searchfox.org/firefox-main/source/__GENERATED__/dist/include
+This mechanism starts with an :ref:`XPIDL` file to define the shape of the interface. In the :searchfox:`build system <xpcom/idl-parser/xpidl>`, this file is processed, and :searchfox:`Rust <__GENERATED__/dist/xpcrs/rt>` and :searchfox:`C++ <__GENERATED__/dist/include>` code is automatically generated.
 
 Next, the interface's methods and attributes must be implemented. This can be done through either a JSM module, or through a C++ interface class. Once these steps are done, the new files must be added to the appropriate :code:`moz.build` files to ensure the build system knows how to find them and process them.
 
@@ -97,7 +93,7 @@ Once :code:`./mach build` is run, the XPIDL parser will read this file, and give
 
 :code:`{obj-directory}/dist/include/nsIComponentName.h`
 
-It might be useful to check out what was automatically generated here, or see the existing `generated C++ header files on SearchFox <https://searchfox.org/firefox-main/source/__GENERATED__/dist/>`_.
+It might be useful to check out what was automatically generated here, or see the existing :searchfox:`generated C++ header files on SearchFox <__GENERATED__/dist/>`.
 
 Writing the C++ implementation
 ------------------------------