Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-23 12:51:06 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1588458 - Replace dxr by searchfox in the rst doc r=ahal DONTBUILD

Browse Source 
Differential Revision: https://phabricator.services.mozilla.com/D49140
This commit is contained in:
Sylvestre Ledru 2020-10-08 08:13:15 +00:00
parent a94fa9e7e0
commit 9bce072e44
23 changed files with 61 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
browser/components/payments/docs/index.rst
View File

@ -92,11 +92,11 @@ The Payment Request UI uses `Custom Elements <https://developer.mozilla.org/en-U
Some guidelines:
* There are some `mixins <https://dxr.mozilla.org/mozilla-central/source/browser/components/payments/res/mixins/>`_
* There are some `mixins <https://searchfox.org/mozilla-central/source/browser/components/payments/res/mixins/>`_
to provide commonly needed functionality to a custom element.
* `res/containers/ <https://dxr.mozilla.org/mozilla-central/source/browser/components/payments/res/containers/>`_
* `res/containers/ <https://searchfox.org/mozilla-central/source/browser/components/payments/res/containers/>`_
contains elements that react to application state changes,
`res/components/ <https://dxr.mozilla.org/mozilla-central/source/browser/components/payments/res/components>`_
`res/components/ <https://searchfox.org/mozilla-central/source/browser/components/payments/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.

4
browser/components/urlbar/docs/index.rst
View File

@ -13,8 +13,8 @@ several different sources, including:
* WebExtensions
* Open tabs
Most of the address bar code lives in `browser/components/urlbar <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/>`_.
A separate and important back-end piece currently is `toolkit/components/places/UnifiedComplete.jsm <https://dxr.mozilla.org/mozilla-central/source/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 <https://searchfox.org/mozilla-central/source/browser/components/urlbar/>`_.
A separate and important back-end piece currently is `toolkit/components/places/UnifiedComplete.jsm <https://searchfox.org/mozilla-central/source/toolkit/components/places/UnifiedComplete.jsm>`_, which was carried over from awesomebar and has not yet been rewritten for quantumbar.
.. toctree::

12
browser/components/urlbar/docs/overview.rst
View File

@ -71,7 +71,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 <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarProvidersManager.jsm>`_,
At the core is the `UrlbarProvidersManager <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarProvidersManager.jsm>`_,
a component tracking all the available search providers, and managing searches
across them.
@ -91,7 +91,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://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarTokenizer.jsm>`_
The *searchString* gets tokenized by the `UrlbarTokenizer <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarTokenizer.jsm>`_
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).
@ -239,7 +239,7 @@ indicated by the UrlbarQueryContext.muxer property.
The Controller
--------------
`UrlbarController <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarController.jsm>`_
`UrlbarController <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarController.jsm>`_
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.
@ -273,7 +273,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 <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm>`_
`UrlbarInput.jsm <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm>`_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Implements an input box *View*, owns an *UrlbarView*.
@ -318,7 +318,7 @@ Implements an input box *View*, owns an *UrlbarView*.
value;
}
`UrlbarView.jsm <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarView.jsm>`_
`UrlbarView.jsm <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarView.jsm>`_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Represents the base *View* implementation, communicates with the *Controller*.
@ -349,7 +349,7 @@ Represents the base *View* implementation, communicates with the *Controller*.
UrlbarResult
------------
An `UrlbarResult <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarResult.jsm>`_
An `UrlbarResult <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarResult.jsm>`_
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

4
browser/components/urlbar/docs/utilities.rst
View File

@ -3,7 +3,7 @@ Utilities
Various modules provide shared utilities to the other components:
`UrlbarPrefs.jsm <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarPrefs.jsm>`_
`UrlbarPrefs.jsm <https://searchfox.org/mozilla-central/source/browser/components/urlbar/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 <https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/UrlbarUtils.jsm>`_
`UrlbarUtils.jsm <https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarUtils.jsm>`_
-------------------------------------------------------------------------------------------------------------
Includes shared utils and constants shared across all the components.

8
browser/docs/BrowserUsageTelemetry.rst
View File

@ -4,7 +4,7 @@
Browser Usage Telemetry
=======================
The `BrowserUsageTelemetry.jsm <https://dxr.mozilla.org/mozilla-central/source/browser/modules/BrowserUsageTelemetry.jsm>`_ module is the main module for measurements regarding the browser usage (e.g. tab and window counts, search counts, ...).
The `BrowserUsageTelemetry.jsm <https://searchfox.org/mozilla-central/source/browser/modules/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 <https://dxr.mozilla.org/mozilla-central/rev/3e73fd638e687a4d7f46613586e5156b8e2af846/browser/base/content/browser.js#3752>`_, 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 <https://searchfox.org/mozilla-central/rev/1a973762afcbc5066f73f1508b0c846872fe3952/browser/base/content/browser.js#4498>`_, 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 <https://dxr.mozilla.org/mozilla-central/search?q=recordSearchInTelemetry>`_.
A list of the components recording search Telemetry can be found using the following `Searchfox search <https://searchfox.org/mozilla-central/search?q=recordSearchInTelemetry>`_.
Tab and window interactions
===========================
@ -25,7 +25,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://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_ for the full list of tracked interactions.
Please see `Scalars.yaml <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_ for the full list of tracked interactions.
Customizable UI
===============

5
build/docs/locales.rst
View File

@ -165,7 +165,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 <https://dxr.mozilla.org/mozilla-central/search?q=path%3Al10n.ini&redirect=true>`_
`few places <https://searchfox.org/mozilla-central/search?q=path%3Al10n.ini&redirect=true>`_
in the source code.
An example looks like this
@ -328,5 +328,4 @@ We host a mercurial repository per locale. All of our
localizations can be found on https://hg.mozilla.org/l10n-central/.
You can search inside our localized files on
`Transvision <https://transvision.mozfr.org/>`_ and
https://dxr.mozilla.org/l10n-central/source/.
`Transvision <https://transvision.mozfr.org/>`_.

4
docs/contributing/debugging/debugging_on_mac_os_x.rst
View File

@ -189,10 +189,10 @@ Setting up lldb
lldb <Debugging Firefox with LLDB>`.
The
`.lldbinit <http://dxr.mozilla.org/mozilla-central/source/.lldbinit>`__
`.lldbinit <http://searchfox.org/mozilla-central/source/.lldbinit>`__
file in the source tree imports many useful `Mozilla specific lldb
settings, commands and
formatters <https://dxr.mozilla.org/mozilla-central/source/python/lldbutils/README.txt>`__
formatters <https://searchfox.org/mozilla-central/source/python/lldbutils/README.txt>`__
into ``lldb``, but you may need to take one of the following steps to
make sure this file is used.

2
docs/contributing/debugging/debugging_on_windows.rst
View File

@ -341,7 +341,7 @@ Debugging JavaScript
Use `Venkman <https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Venkman>`__, the JavaScript Debugger for Mozilla.
You can use helper functions from
`nsXPConnect.cpp <https://dxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/nsXPConnect.cpp#1395>`__
`nsXPConnect.cpp <https://searchfox.org/mozilla-central/source/js/xpconnect/src/nsXPConnect.cpp>`__
to inspect and modify the state of JavaScript code from the MSVS
debugger.

2
mobile/android/docs/uitelemetry.rst
View File

@ -114,7 +114,7 @@ Clock
Times are relative to either elapsed realtime (an arbitrary monotonically increasing clock that continues to tick when the device is asleep), or elapsed uptime (which doesn't tick when the device is in deep sleep). We default to elapsed realtime.
See the documentation in `the source <http://dxr.mozilla.org/mozilla-central/source/mobile/android/base/Telemetry.java>`_ for more details.
See the documentation in `the source <https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/RuntimeTelemetry.java>`_ for more details.
Dictionary
==========

2
services/common/docs/RemoteSettings.rst
View File

@ -4,7 +4,7 @@
Remote Settings
===============
The `remote-settings.js <https://dxr.mozilla.org/mozilla-central/source/services/settings/remote-settings.js>`_ module offers the ability to fetch remote settings that are kept in sync with Mozilla servers.
The `remote-settings.js <https://searchfox.org/mozilla-central/source/services/settings/remote-settings.js>`_ module offers the ability to fetch remote settings that are kept in sync with Mozilla servers.
Usage

2
taskcluster/docs/partner-repacks.rst
View File

@ -40,7 +40,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()
<python/taskgraph.util.html#taskgraph.util.partners.get_partner_config_by_url>`_ function, with the
url defined in `taskcluster/ci/config.yml <https://dxr.mozilla
url defined in `taskcluster/ci/config.yml <https://searchfox
.org/mozilla-release/search?q=regexp%3A^partner+path%3Aconfig.yml&redirect=true>`_.
``release_partner_build_number`` is an integer used to create unique upload paths in the firefox

2
taskcluster/docs/release-promotion-action.rst
View File

@ -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

2
taskcluster/docs/taskgraph.rst
View File

@ -221,7 +221,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
<https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/config.py>`_.
<https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/config.py>`_.
.. _taskgraph-trust-domain:

2
toolkit/components/telemetry/docs/collection/events.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Events.yaml>`_.
For any code that ships as part of Firefox that happens in `Events.yaml <https://searchfox.org/mozilla-central/source/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.:

6
toolkit/components/telemetry/docs/collection/histograms.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json>`_ file. These declarations are checked for correctness at `compile time <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/gen_histogram_data.py>`_ and used to generate C++ code.
Histograms should be declared in the `Histograms.json <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json>`_ file. These declarations are checked for correctness at `compile time <https://searchfox.org/mozilla-central/source/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:
@ -276,7 +276,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://dxr.mozilla.org/mozilla-central/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 `nsITelemetry <https://searchfox.org/mozilla-central/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:
.. code-block:: js
@ -305,7 +305,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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/nsITelemetry.idl>`_ interface, but the helper functions declared in `Telemetry.h <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Telemetry.h>`_ are more convenient:
Probes in native code can also use the `nsITelemetry <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/nsITelemetry.idl>`_ interface, but the helper functions declared in `Telemetry.h <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Telemetry.h>`_ are more convenient:
.. code-block:: cpp

18
toolkit/components/telemetry/docs/collection/scalars.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/core/nsITelemetry.idl>`_
or the `C++ API <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/core/Telemetry.h>`_.
Scalar probes can be managed either through the `nsITelemetry interface <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/core/nsITelemetry.idl>`_
or the `C++ API <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/core/Telemetry.h>`_.
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 <https://dxr.mozilla.org/mozilla-central/search?q=regexp%3ATelemetryScalar%3A%3A(Set%7CAdd)+file%3ATelemetryScalar.cpp&redirect=false>`_ for
(e.g. calling scalarSetMaximum on a scalar of the string kind). Please look at the `code documentation <https://searchfox.org/mozilla-central/search?q=TelemetryScalar%3A%3A%28Set%7CAdd%29&path=TelemetryScalar.cpp&case=false&regexp=true>`_ for
additional information.
.. _registerscalars:
@ -89,7 +89,7 @@ Example:
C++ API
-------
Probes in native code can use the more convenient helper functions declared in `Telemetry.h <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/core/Telemetry.h>`_:
Probes in native code can use the more convenient helper functions declared in `Telemetry.h <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/core/Telemetry.h>`_:
.. code-block:: cpp
@ -111,7 +111,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://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_
in the `Scalars.yaml <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_
definition file.
The probes in the definition file are represented in a fixed-depth, two-level structure:
@ -243,7 +243,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://dxr.mozilla.org/mozilla-central/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 `Scalars.yaml <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_ definition file: a simple boolean scalar and a keyed unsigned scalar.
.. code-block:: yaml
@ -294,7 +294,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://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_TelemetryScalars.js>`_ and `child processes scalars <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_ChildScalars.js>`_.
More usage examples can be found in the tests covering the `JS Scalars API <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_TelemetryScalars.js>`_ and `child processes scalars <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_ChildScalars.js>`_.
Using the C++ API
-----------------
@ -307,9 +307,9 @@ Native code can take advantage of Scalars as well, by including the ``Telemetry.
Telemetry::ScalarAdd(Telemetry::ScalarID::UI_DOWNLOAD_BUTTON_ACTIVATED,
u"touchscreen"_ns, 1);
The ``ScalarID`` enum is automatically generated by the build process, with an example being available `here <https://dxr.mozilla.org/mozilla-central/search?q=path%3ATelemetryScalarEnums.h&redirect=false>`_ .
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://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/tests/gtest/TestScalars.cpp>`_ for the scalars C++ API.
Other examples can be found in the `test coverage <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/gtest/TestScalars.cpp>`_ for the scalars C++ API.
Version History
===============

8
toolkit/components/telemetry/docs/collection/use-counters.rst
View File

@ -29,7 +29,7 @@ Example scenarios:
Deprecated DOM operations
-------------------------
Use counters for deprecated DOM operations are declared in the `nsDeprecatedOperationList.h <https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDeprecatedOperationList.h>`_ file. The counters are
Use counters for deprecated DOM operations are declared in the `nsDeprecatedOperationList.h <https://searchfox.org/mozilla-central/source/dom/base/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 <https://dxr.mozilla.org/mozilla-central/source/dom/base/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 <https://searchfox.org/mozilla-central/source/dom/base/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 <description> 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 <https://dxr.mozilla.org/mozilla-central/source/dom/base/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 <https://searchfox.org/mozilla-central/source/dom/base/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 <https://dxr.mozilla.org/mozilla-central/rev/b056526be38e96b3e381b7e90cd8254ad1d96d9d/dom/base/nsDocument.cpp#13209-13231>`__). The difference between the values of these two histograms
`here <https://searchfox.org/mozilla-central/rev/1a973762afcbc5066f73f1508b0c846872fe3952/dom/base/Document.cpp#15059-15081>`__). 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*

14
toolkit/components/telemetry/docs/data/main-ping.rst
View File

@ -133,11 +133,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 <https://dxr.mozilla.org/mozilla-central/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 :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 <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/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 <https://dxr.mozilla.org/mozilla-central/search?q=%22TelemetryTimestamps.add%22&redirect=false&case=true>`__ and `here <https://dxr.mozilla.org/mozilla-central/search?q=%22recordTimestamp%22&redirect=false&case=true>`__) can be reported.
This section contains a list of simple measurements, or counters. In addition to the ones highlighted below, Telemetry timestamps (see `here <https://searchfox.org/mozilla-central/search?q=TelemetryTimestamps.add&redirect=false&case=true>`__ and `here <https://searchfox.org/mozilla-central/search?q=recordTimestamp&redirect=false&case=true>`__) can be reported.
totalTime
~~~~~~~~~
@ -145,7 +145,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 <https://dxr.mozilla.org/mozilla-central/search?q=%22AddonManagerPrivate.recordSimpleMeasure%22&redirect=false&case=true>`__ 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 <https://searchfox.org/mozilla-central/search?q=AddonManagerPrivate.recordSimpleMeasure&redirect=false&case=true>`__ for a list of recorded measures.
UITelemetry
~~~~~~~~~~~
@ -205,13 +205,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://dxr.mozilla.org/mozilla-central/rev/e6463ae7eda2775bc84593bb4a0742940bb87379/dom/events/EventStateManager.cpp#549>`_).
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/mozilla-central/source/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://dxr.mozilla.org/mozilla-central/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 `here <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json>`__. The ``info.revision`` field indicates the revision of the file that describes the reported histograms.
keyedHistograms
---------------
@ -408,7 +408,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 <https://dxr.mozilla.org/mozilla-central/search?q=setTelemetryDetails&case=true>`_). 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 <https://searchfox.org/mozilla-central/search?q=setTelemetryDetails&case=true>`_). Telemetry does not manipulate or enforce a specific format for the supplied provider's data.
Structure:
@ -457,7 +457,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 <https://dxr.mozilla.org/mozilla-central/search?q=regexp%3AUITelemetry.%28addEvent|startSession|stopSession%29&redirect=false&case=false>`_).
This section is Android-only and contains UI specific Telemetry measurements and events (`see here <https://searchfox.org/mozilla-central/search?q=UITelemetry.%28addEvent|startSession|stopSession%29&redirect=false&case=false&regexp=true>`_).
Structure:

2
toolkit/components/telemetry/docs/data/new-profile-ping.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_ file.
The recorded scalars are described in the `Scalars.yaml <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml>`_ file.
Duplicate pings
---------------

8
toolkit/components/telemetry/docs/data/sync-ping.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/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 <https://searchfox.org/mozilla-central/source/services/sync/tests/unit/sync_ping_schema.json>`_.
Structure:
@ -171,7 +171,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 <https://dxr.mozilla.org/mozilla-central/source/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 <https://searchfox.org/mozilla-central/source/services/sync/modules/constants.js>`_, and success values are not reported.
syncs.failureReason
~~~~~~~~~~~~~~~~~~~
@ -192,7 +192,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 <https://dxr.mozilla.org/mozilla-central/source/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 <https://searchfox.org/mozilla-central/source/services/sync/modules/constants.js>`_.
- ``error``: String identifying which error was present.
@ -212,7 +212,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 <https://dxr.mozilla.org/mozilla-central/source/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 <https://searchfox.org/mozilla-central/source/services/sync/modules/bookmark_validator.js>`_ for an example.
syncs.devices
~~~~~~~~~~~~~

6
toolkit/components/telemetry/docs/obsolete/hybrid-content.rst
View File

@ -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 <https://dxr.mozilla.org/mozilla-central/source/browser/app/permissions>`_ .
`browser/app/permissions <https://searchfox.org/mozilla-central/source/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 <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/hybrid-content/HybridContentTelemetry-lib.js>`_ library.
The hybrid content API is available to the web content through the inclusion of the `HybridContentTelemetry-lib.js <https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/hybrid-content/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 <https://dxr.mozilla.org/mozilla-central/source/browser/app/permissions>`_
Adding the ``hc_telemetry`` permission for a new domain in `browser/app/permissions <https://searchfox.org/mozilla-central/source/browser/app/permissions>`_
requires `Data Collection Review <https://wiki.mozilla.org/Firefox/Data_Collection>`_ 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.

2
toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
View File

@ -129,7 +129,7 @@ Any data collection that you need to base decisions on needs to have test covera
- for events, `snapshotEvents() <https://searchfox.org/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://dxr.mozilla.org/mozilla-central/search?q=TelemetryArchiveTesting&redirect=false>`_.
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>`_.
Validation
----------

2
tools/code-coverage/docs/index.rst
View File

@ -149,7 +149,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/taskgraph/transforms/tests.py <https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/transforms/tests.py#516>`__
`taskcluster/taskgraph/transforms/tests.py <https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/transforms/tests.py#516>`__
and add the following line,
.. code:: python