diff --git a/browser/components/payments/docs/index.rst b/browser/components/payments/docs/index.rst index e34d64577c07..3fbb26dfab7e 100644 --- a/browser/components/payments/docs/index.rst +++ b/browser/components/payments/docs/index.rst @@ -91,11 +91,11 @@ The Payment Request UI uses `Custom Elements `_ +* There are some `mixins `_ to provide commonly needed functionality to a custom element. -* `res/containers/ `_ +* `res/containers/ `_ contains elements that react to application state changes, - `res/components/ `_ + `res/components/ `_ contains elements that aren't connected to the state directly. * Elements should avoid having their own internal/private state and should react to state changes. Containers primarily use the application state (``requestStore``) while components primarily use attributes. diff --git a/browser/components/urlbar/docs/index.rst b/browser/components/urlbar/docs/index.rst index bf04baebf798..633bca91b606 100644 --- a/browser/components/urlbar/docs/index.rst +++ b/browser/components/urlbar/docs/index.rst @@ -13,8 +13,8 @@ several different sources, including: * WebExtensions * Open tabs -Most of the address bar code lives in `browser/components/urlbar `_. -A separate and important back-end piece currently is `toolkit/components/places/UnifiedComplete.jsm `_, which was carried over from awesomebar and has not yet been rewritten for quantumbar. +Most of the address bar code lives in `browser/components/urlbar `_. +A separate and important back-end piece currently is `toolkit/components/places/UnifiedComplete.jsm `_, which was carried over from awesomebar and has not yet been rewritten for quantumbar. .. toctree:: diff --git a/browser/components/urlbar/docs/overview.rst b/browser/components/urlbar/docs/overview.rst index b8172328575f..493c18df7401 100644 --- a/browser/components/urlbar/docs/overview.rst +++ b/browser/components/urlbar/docs/overview.rst @@ -60,7 +60,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 `UrlbarProvidersManager `_, +At the core is the `UrlbarProvidersManager `_, a component tracking all the available search providers, and managing searches across them. @@ -80,7 +80,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 `_ +The *searchString* gets tokenized by the `UrlbarTokenizer `_ 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). @@ -226,7 +226,7 @@ indicated by the UrlbarQueryContext.muxer property. The Controller -------------- -`UrlbarController `_ +`UrlbarController `_ 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. @@ -260,7 +260,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.jsm `_ +`UrlbarInput.jsm `_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Implements an input box *View*, owns an *UrlbarView*. @@ -307,7 +307,7 @@ Implements an input box *View*, owns an *UrlbarView*. value; } -`UrlbarView.jsm `_ +`UrlbarView.jsm `_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Represents the base *View* implementation, communicates with the *Controller*. @@ -338,7 +338,7 @@ Represents the base *View* implementation, communicates with the *Controller*. UrlbarResult ------------ -An `UrlbarResult `_ +An `UrlbarResult `_ 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/utilities.rst b/browser/components/urlbar/docs/utilities.rst index a1ccd4f21acc..8fa3b8509e7a 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.jsm `_ +`UrlbarPrefs.jsm `_ ------------------------------------------------------------------------------------------------------------- Implements a Map-like storage or urlbar related preferences. The values are kept @@ -20,7 +20,7 @@ up-to-date. Newly added preferences should always be properly documented in UrlbarPrefs. -`UrlbarUtils.jsm `_ +`UrlbarUtils.jsm `_ ------------------------------------------------------------------------------------------------------------- Includes shared utils and constants shared across all the components. diff --git a/browser/docs/BrowserUsageTelemetry.rst b/browser/docs/BrowserUsageTelemetry.rst index c49cf7a3ac16..c7726a4a98e9 100644 --- a/browser/docs/BrowserUsageTelemetry.rst +++ b/browser/docs/BrowserUsageTelemetry.rst @@ -4,7 +4,7 @@ Browser Usage Telemetry ======================= -The `BrowserUsageTelemetry.jsm `_ module is the main module for measurements regarding the browser usage (e.g. tab and window counts, search counts, ...). +The `BrowserUsageTelemetry.jsm `_ 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). @@ -12,9 +12,9 @@ Search telemetry ================ This module exposes the ``recordSearch`` method, which serves as the main entry point for recording search related Telemetry. It records only the search *counts* per engine and the origin of the search, but nothing pertaining the search contents themselves. -As the transition to the ``BrowserUsageTelemetry`` happens, the ``recordSearch`` calls are dispatched through `BrowserSearch.recordSearchInTelemetry `_, that is called by all the search related UI components (urlbar, searchbar, context menu and about\:\* pages). +As the transition to the ``BrowserUsageTelemetry`` happens, the ``recordSearch`` calls are dispatched through `BrowserSearch.recordSearchInTelemetry `_, that is called by all the search related UI components (urlbar, searchbar, context menu and about\:\* pages). -A list of the components recording search Telemetry can be found using the following `DXR search `_. +A list of the components recording search Telemetry can be found using the following `DXR search `_. Measured interactions ===================== @@ -25,4 +25,4 @@ 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 `_ for the full list of tracked interactions. +Please see `Scalars.yaml `_ for the full list of tracked interactions. diff --git a/build/docs/rust.rst b/build/docs/rust.rst index acdb07b20a57..ca8e4e29de13 100644 --- a/build/docs/rust.rst +++ b/build/docs/rust.rst @@ -13,16 +13,16 @@ 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 `_. +``dependencies`` section of `toolkit/library/rust/shared/Cargo.toml `_. After adding your crate, execute ``cargo update -p gkrust-shared`` to update the ``Cargo.lock`` file. You'll also need to add an ``extern crate`` reference to -`toolkit/library/rust/shared/lib.rs `_. +`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. By default, all Cargo packages in the mozilla-central repository are part of -the same `workspace `_ +the same `workspace `_ 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 ``excludes`` list in the top-level ``Cargo.toml`` file. You may want to do @@ -41,7 +41,7 @@ a ``Cargo.toml`` file for your crate, and a ``moz.build`` file that contains: 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 `_ and `the Cargo.toml file `_ that are used for libxul. +``Cargo.toml``. You can refer to `the moz.build file `_ and `the Cargo.toml file `_ 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. diff --git a/services/common/docs/RemoteSettings.rst b/services/common/docs/RemoteSettings.rst index ccba1aba803a..f0e0f00bcceb 100644 --- a/services/common/docs/RemoteSettings.rst +++ b/services/common/docs/RemoteSettings.rst @@ -4,7 +4,7 @@ Remote Settings =============== -The `remote-settings.js `_ module offers the ability to fetch remote settings that are kept in sync with Mozilla servers. +The `remote-settings.js `_ module offers the ability to fetch remote settings that are kept in sync with Mozilla servers. Usage diff --git a/taskcluster/docs/partner-repacks.rst b/taskcluster/docs/partner-repacks.rst index bda748fa12d0..45813f4b9036 100644 --- a/taskcluster/docs/partner-repacks.rst +++ b/taskcluster/docs/partner-repacks.rst @@ -30,7 +30,7 @@ Partner repacks have a number of parameters which control how they work: We split the repacks into two 'paths', EME-free and everything else, to retain some flexibility over enabling/disabling them separately. This costs us some duplication of the kinds in the repacking stack. The two enable parameters are booleans to turn these two paths -on/off. We set them in release-runner3's `is_partner_enabled() `_ when starting a release. They're both true for Firefox betas >= b8 and releases, but otherwise disabled. @@ -38,7 +38,7 @@ release. They're both true for Firefox betas >= b8 and releases, but otherwise d logic. It's usually looked up during the release promotion action task, using the Github GraphQL API in the `get_partner_config_by_url() `_ function, with the -url defined in `taskcluster/ci/config.yml `_. ``release_partner_build_number`` is an integer used to create unique upload paths in the firefox diff --git a/taskcluster/docs/release-promotion-action.rst b/taskcluster/docs/release-promotion-action.rst index 6d2a052cf81a..005c03168546 100644 --- a/taskcluster/docs/release-promotion-action.rst +++ b/taskcluster/docs/release-promotion-action.rst @@ -166,5 +166,5 @@ The ``parameters.yml`` file is downloadable from a previous decision or action t .. _Release Promotion Projects: https://searchfox.org/mozilla-central/search?q=RELEASE_PROMOTION_PROJECTS&path=taskcluster/taskgraph/util/attributes.py .. _Releaserunner3: https://hg.mozilla.org/build/tools/file/tip/buildfarm/release .. _releasewarrior docs: https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/release-promotion/desktop/howto.md#how -.. _trigger_action.py: https://dxr.mozilla.org/build-central/source/tools/buildfarm/release/trigger_action.py#118 +.. _trigger_action.py: https://searchfox.org/build-central/source/tools/buildfarm/release/trigger_action.py#118 .. _.taskcluster.yml: https://searchfox.org/mozilla-central/source/.taskcluster.yml diff --git a/taskcluster/docs/taskgraph.rst b/taskcluster/docs/taskgraph.rst index 53693a89cbf9..20f4fe96f8c5 100644 --- a/taskcluster/docs/taskgraph.rst +++ b/taskcluster/docs/taskgraph.rst @@ -202,7 +202,7 @@ 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/ci/`). The available settings are documented inline in `taskcluster/taskgraph/config.py -`_. +`_. .. _taskgraph-trust-domain: diff --git a/taskcluster/docs/try.rst b/taskcluster/docs/try.rst index 95f898fe44eb..c23733695cb5 100644 --- a/taskcluster/docs/try.rst +++ b/taskcluster/docs/try.rst @@ -171,9 +171,9 @@ config. } .. _JSON-e: https://taskcluster.github.io/json-e/ -.. _taskgraph module: https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/templates +.. _taskgraph module: https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/templates .. _condition statements: https://taskcluster.github.io/json-e/#%60$if%60%20-%20%60then%60%20-%20%60else%60 -.. _existing templates: https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/templates +.. _existing templates: https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/templates .. _SCM Level: https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ diff --git a/toolkit/components/telemetry/docs/collection/events.rst b/toolkit/components/telemetry/docs/collection/events.rst index f018b77e9224..49ef34a4fa2c 100644 --- a/toolkit/components/telemetry/docs/collection/events.rst +++ b/toolkit/components/telemetry/docs/collection/events.rst @@ -80,7 +80,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 `_. +For any code that ships as part of Firefox that happens in `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/collection/histograms.rst b/toolkit/components/telemetry/docs/collection/histograms.rst index 8920158f65cf..920ce2cbb2e5 100644 --- a/toolkit/components/telemetry/docs/collection/histograms.rst +++ b/toolkit/components/telemetry/docs/collection/histograms.rst @@ -106,7 +106,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 `_ file. These declarations are checked for correctness at `compile time `_ and used to generate C++ code. +Histograms should be declared in the `Histograms.json `_ file. These declarations are checked for correctness at `compile time `_ 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: @@ -274,7 +274,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 `_ 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 `nsITelemetry `_ 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 @@ -303,7 +303,7 @@ For histograms measuring time, TelemetryStopwatch can be used to avoid working w Adding a C++ Probe ================== -Probes in native code can also use the `nsITelemetry `_ interface, but the helper functions declared in `Telemetry.h `_ are more convenient: +Probes in native code can also use the `nsITelemetry `_ interface, but the helper functions declared in `Telemetry.h `_ are more convenient: .. code-block:: cpp diff --git a/toolkit/components/telemetry/docs/collection/hybrid-content.rst b/toolkit/components/telemetry/docs/collection/hybrid-content.rst index 68eb091cc7b3..a3d7412fb6fe 100644 --- a/toolkit/components/telemetry/docs/collection/hybrid-content.rst +++ b/toolkit/components/telemetry/docs/collection/hybrid-content.rst @@ -27,7 +27,7 @@ Granting the privileges ----------------------- For security/privacy reasons `Mozilla.ContentTelemetry` will only work on a list of allowed secure origins. The list of allowed origins can be found in -`browser/app/permissions `_ . +`browser/app/permissions `_ . A host needs to be given the ``hc_telemetry`` permission in order to be allowed to use the API. Example: @@ -216,7 +216,7 @@ Example: The API ======= -The hybrid content API is available to the web content through the inclusion of the `HybridContentTelemetry-lib.js `_ library. +The hybrid content API is available to the web content through the inclusion of the `HybridContentTelemetry-lib.js `_ library. The initial implementation of the API allows the registration and the recording of events. @@ -321,7 +321,7 @@ Example: Data Review =========== -Adding the ``hc_telemetry`` permission for a new domain in `browser/app/permissions `_ +Adding the ``hc_telemetry`` permission for a new domain in `browser/app/permissions `_ requires `Data Collection Review `_ as we are enabling a new method of data collection. Giving a domain permission to use Hybrid Content Telemetry also gives any Extensions running on this domain permission to use Hybrid Content Telemetry. diff --git a/toolkit/components/telemetry/docs/collection/scalars.rst b/toolkit/components/telemetry/docs/collection/scalars.rst index ac940223d8e5..669fef8e121e 100644 --- a/toolkit/components/telemetry/docs/collection/scalars.rst +++ b/toolkit/components/telemetry/docs/collection/scalars.rst @@ -18,8 +18,8 @@ The serialized scalar data is submitted with the :doc:`main pings <../data/main- The API ======= -Scalar probes can be managed either through the `nsITelemetry interface `_ -or the `C++ API `_. +Scalar probes can be managed either through the `nsITelemetry interface `_ +or the `C++ API `_. JS API ------ @@ -36,7 +36,7 @@ Probes in privileged JavaScript code can use the following functions to manipula Services.telemetry.keyedScalarSetMaximum(aName, aKey, aValue); These functions can throw if, for example, an operation is performed on a scalar type that doesn't support it -(e.g. calling scalarSetMaximum on a scalar of the string kind). Please look at the `code documentation `_ for +(e.g. calling scalarSetMaximum on a scalar of the string kind). Please look at the `code documentation `_ for additional information. .. _registerscalars: @@ -86,7 +86,7 @@ Example: C++ API ------- -Probes in native code can use the more convenient helper functions declared in `Telemetry.h `_: +Probes in native code can use the more convenient helper functions declared in `Telemetry.h `_: .. code-block:: cpp @@ -108,7 +108,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 `_ +in the `Scalars.yaml `_ definition file. The probes in the definition file are represented in a fixed-depth, two-level structure: @@ -237,7 +237,7 @@ Making a scalar measurement is a two step process: Registering the scalar ---------------------- -Let's start by registering two probes in the `Scalars.yaml `_ definition file: a simple boolean scalar and a keyed unsigned scalar. +Let's start by registering two probes in the `Scalars.yaml `_ definition file: a simple boolean scalar and a keyed unsigned scalar. .. code-block:: yaml @@ -288,7 +288,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 `_ and `child processes scalars `_. +More usage examples can be found in the tests covering the `JS Scalars API `_ and `child processes scalars `_. Using the C++ API ----------------- @@ -301,9 +301,9 @@ Native code can take advantage of Scalars as well, by including the ``Telemetry. Telemetry::ScalarAdd(Telemetry::ScalarID::UI_DOWNLOAD_BUTTON_ACTIVATED, NS_LITERAL_STRING("touchscreen"), 1); -The ``ScalarID`` enum is automatically generated by the build process, with an example being available `here `_ . +The ``ScalarID`` enum is automatically generated by the build process, with an example being available `here `_ . -Other examples can be found in the `test coverage `_ for the scalars C++ API. +Other examples can be found in the `test coverage `_ for the scalars C++ API. Version History =============== diff --git a/toolkit/components/telemetry/docs/collection/stack-capture.rst b/toolkit/components/telemetry/docs/collection/stack-capture.rst index 2eef1ffbbcbf..30aa62dd4a78 100644 --- a/toolkit/components/telemetry/docs/collection/stack-capture.rst +++ b/toolkit/components/telemetry/docs/collection/stack-capture.rst @@ -19,8 +19,8 @@ The serialized stack data is submitted with the :doc:`main pings <../data/main-p The API ======= -Capturing stacks is available either via the `nsITelemetry interface `_ -or the `C++ API `_. +Capturing stacks is available either via the `nsITelemetry interface `_ +or the `C++ API `_. Note that current implementation of the API is not thread safe. Also, capturing stacks in the content process is not supported yet. @@ -41,7 +41,7 @@ walking. ``aKey`` is a string used primarily as an identifier for a captured stack. It can be used to identify stacks down the data processing pipeline and on ``about:telemetry``. -For more technical information please refer to the `code documentation `_ . +For more technical information please refer to the `code documentation `_ . C++ API ------- diff --git a/toolkit/components/telemetry/docs/collection/use-counters.rst b/toolkit/components/telemetry/docs/collection/use-counters.rst index 39c6388370a6..1e6f5227f41e 100644 --- a/toolkit/components/telemetry/docs/collection/use-counters.rst +++ b/toolkit/components/telemetry/docs/collection/use-counters.rst @@ -29,7 +29,7 @@ Example scenarios: Deprecated DOM operations ------------------------- -Use counters for deprecated DOM operations are declared in the `nsDeprecatedOperationList.h `_ file. The counters are +Use counters for deprecated DOM operations are declared in the `nsDeprecatedOperationList.h `_ file. The counters are registered through the ``DEPRECATED_OPERATION(DeprecationReference)`` macro. The provided parameter must have the same value of the deprecation note added to the *IDL* file. @@ -43,7 +43,7 @@ Use counters for CSS properties are generated for every property Gecko supports The UseCounters registry ------------------------ -Use counters for WebIDL methods/attributes are registered in the `UseCounters.conf `_ file. The format of this file is very strict. Each line can be: +Use counters for WebIDL methods/attributes are registered in the `UseCounters.conf `_ file. The format of this file is very strict. Each line can be: 1. a blank line 2. a comment, which is a line that begins with ``//`` @@ -59,7 +59,7 @@ The for custom counters will be appended to "When a document " or WebIDL methods and attributes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Additionally to having a new entry added to the `UseCounters.conf `_ file, WebIDL methods and attributes must have a ``[UseCounter]`` extended attribute in the Web IDL file in order for the counters to be incremented. +Additionally to having a new entry added to the `UseCounters.conf `_ file, WebIDL methods and attributes must have a ``[UseCounter]`` extended attribute in the Web IDL file in order for the counters to be incremented. Both additions are required because generating things from bindings codegen and ensuring all the dependencies are correct would have been rather difficult. @@ -87,7 +87,7 @@ the use counter directly reports if a feature was used but it does not directly it isn't used. The values accumulated within a use counter should be considered proportional to ``CONTENT_DOCUMENTS_DESTROYED`` and ``TOP_LEVEL_CONTENT_DOCUMENTS_DESTROYED`` (see -`here `__). The difference between the values of these two histograms +`here `__). The difference between the values of these two histograms and the related use counters below tell us how many pages did *not* use the feature in question. For instance, if we see that a given session has destroyed 30 content documents, but a particular use counter shows only a count of 5, we can infer that the use counter was *not* diff --git a/toolkit/components/telemetry/docs/data/main-ping.rst b/toolkit/components/telemetry/docs/data/main-ping.rst index 27694a4d7df3..15b182e91643 100644 --- a/toolkit/components/telemetry/docs/data/main-ping.rst +++ b/toolkit/components/telemetry/docs/data/main-ping.rst @@ -135,11 +135,11 @@ This format was adopted in Firefox 51 via bug 1218576. scalars and keyedScalars ~~~~~~~~~~~~~~~~~~~~~~~~ -This section contains the :doc:`../collection/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 `_ file. The ``info.revision`` field indicates the revision of the file that describes the reported scalars. +This section contains the :doc:`../collection/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 `_ file. The ``info.revision`` field indicates the revision of the file that describes the reported scalars. simpleMeasurements ------------------ -This section contains a list of simple measurements, or counters. In addition to the ones highlighted below, Telemetry timestamps (see `here `__ and `here `__) can be reported. +This section contains a list of simple measurements, or counters. In addition to the ones highlighted below, Telemetry timestamps (see `here `__ and `here `__) can be reported. totalTime ~~~~~~~~~ @@ -147,7 +147,7 @@ A non-monotonic integer representing the number of seconds the session has been addonManager ~~~~~~~~~~~~ -Only available in the extended set of measures, it contains a set of counters related to Addons. See `here `__ for a list of recorded measures. +Only available in the extended set of measures, it contains a set of counters related to Addons. See `here `__ for a list of recorded measures. UITelemetry ~~~~~~~~~~~ @@ -207,13 +207,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 `_). +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 `_). 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 `_. 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 `here `_. The ``info.revision`` field indicates the revision of the file that describes the reported histograms. keyedHistograms --------------- @@ -595,7 +595,7 @@ Structure: addonDetails ------------ -This section contains per add-on telemetry details, as reported by each add-on provider. The XPI provider is the only one reporting at the time of writing (`see DXR `_). Telemetry does not manipulate or enforce a specific format for the supplied provider's data. +This section contains per add-on telemetry details, as reported by each add-on provider. The XPI provider is the only one reporting at the time of writing (`see DXR `_). Telemetry does not manipulate or enforce a specific format for the supplied provider's data. Structure: @@ -644,7 +644,7 @@ This section contains the slow SQL statements gathered at startup (until the "se UIMeasurements -------------- -This section is Android-only and contains UI specific Telemetry measurements and events (`see here `_). +This section is Android-only and contains UI specific Telemetry measurements and events (`see here `_). Structure: diff --git a/toolkit/components/telemetry/docs/data/new-profile-ping.rst b/toolkit/components/telemetry/docs/data/new-profile-ping.rst index 3f7958a62ff6..67a95b45b4ca 100644 --- a/toolkit/components/telemetry/docs/data/new-profile-ping.rst +++ b/toolkit/components/telemetry/docs/data/new-profile-ping.rst @@ -52,7 +52,7 @@ scalars This section contains the :doc:`../collection/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 `_ file. +The recorded scalars are described in the `Scalars.yaml `_ file. Duplicate pings --------------- diff --git a/toolkit/components/telemetry/docs/data/sync-ping.rst b/toolkit/components/telemetry/docs/data/sync-ping.rst index 97753a55ceae..9ef00e81d963 100644 --- a/toolkit/components/telemetry/docs/data/sync-ping.rst +++ b/toolkit/components/telemetry/docs/data/sync-ping.rst @@ -6,7 +6,7 @@ This is an aggregated format that contains information about each sync that occu Each item in the ``syncs`` property is generated after a sync is completed, for both successful and failed syncs, and contains measurements pertaining to sync performance and error information. -A JSON-schema document describing the exact format of the ping's payload property can be found at `services/sync/tests/unit/sync\_ping\_schema.json `_. +A JSON-schema document describing the exact format of the ping's payload property can be found at `services/sync/tests/unit/sync\_ping\_schema.json `_. Structure: @@ -156,7 +156,7 @@ One of the following values: syncs.status ~~~~~~~~~~~~ -The ``engine.status``, ``payload.status.sync``, and ``payload.status.service`` properties are sync error codes, which are listed in `services/sync/modules/constants.js `_, and success values are not reported. +The ``engine.status``, ``payload.status.sync``, and ``payload.status.service`` properties are sync error codes, which are listed in `services/sync/modules/constants.js `_, and success values are not reported. syncs.failureReason ~~~~~~~~~~~~~~~~~~~ @@ -177,7 +177,7 @@ Stores error information, if any is present. Always contains the "name" property - ``from``: Where the authentication error occurred, one of the following values: ``tokenserver``, ``fxaccounts``, or ``hawkclient``. -- ``othererror``: Indicates that it is a sync error code that we are unable to give more specific information on. As with the ``syncStatus`` property, it is a sync error code, which are listed in `services/sync/modules/constants.js `_. +- ``othererror``: Indicates that it is a sync error code that we are unable to give more specific information on. As with the ``syncStatus`` property, it is a sync error code, which are listed in `services/sync/modules/constants.js `_. - ``error``: String identifying which error was present. @@ -197,7 +197,7 @@ Third-party engines are not reported, so only the following values are allowed: syncs.engine.validation.problems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For engines that can run validation on themselves, an array of objects describing validation errors that have occurred. Items that would have a count of 0 are excluded. Each engine will have its own set of items that it might put in the ``name`` field, but there are a finite number. See ``BookmarkProblemData.getSummary`` in `services/sync/modules/bookmark\_validator.js `_ for an example. +For engines that can run validation on themselves, an array of objects describing validation errors that have occurred. Items that would have a count of 0 are excluded. Each engine will have its own set of items that it might put in the ``name`` field, but there are a finite number. See ``BookmarkProblemData.getSummary`` in `services/sync/modules/bookmark\_validator.js `_ for an example. syncs.devices ~~~~~~~~~~~~~ diff --git a/toolkit/components/telemetry/docs/internals/geckoview.rst b/toolkit/components/telemetry/docs/internals/geckoview.rst index 8161584920cf..6e7cf4a9820c 100644 --- a/toolkit/components/telemetry/docs/internals/geckoview.rst +++ b/toolkit/components/telemetry/docs/internals/geckoview.rst @@ -10,8 +10,8 @@ GeckoView support is limited to :doc:`scalars <../collection/scalars>` and Overview -------- -GeckoView does not make use of the same `JavaScript modules `_ -used in Firefox Desktop. Instead, Telemetry gets setup on this product by `GeckoViewTelemetryController.jsm `_ . +GeckoView does not make use of the same `JavaScript modules `_ +used in Firefox Desktop. Instead, Telemetry gets setup on this product by `GeckoViewTelemetryController.jsm `_ . More importantly, users do not need to worry about handling measurements' persistence across sessions: this means measurements accumulate across application sessions until cleared. In 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 6ccbbdb71d01..7f191a818e37 100644 --- a/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst +++ b/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst @@ -129,7 +129,7 @@ Any data collection that you need to base decisions on needs to have test covera - for events, `snapshotEvents() `_ -If you need to test that pings were correctly passed to Telemetry, you can use `TelemetryArchiveTesting `_. +If you need to test that pings were correctly passed to Telemetry, you can use `TelemetryArchiveTesting `_. Validation ---------- diff --git a/tools/compare-locales/docs/index.rst b/tools/compare-locales/docs/index.rst index 3820cef98dc3..977934150b65 100644 --- a/tools/compare-locales/docs/index.rst +++ b/tools/compare-locales/docs/index.rst @@ -45,7 +45,7 @@ The first thing to note is that only files beneath :file:`locales/en-US` are exposed to localizers. The second thing to note is that only a few directories are exposed. Which directories are exposed is defined in files called ``l10n.ini``, which are at a -`few places `_ +`few places `_ in the source code. An example looks like this