Bug 1433417 - Fix a bunch of typo in the doc r=ahal

MozReview-Commit-ID: LRgL0CMJdDP

--HG--
extra : rebase_source : b99364bb96c1501a674a1726a3b5fdf0664a8e4f

browser/experiments/docs/manifest.rst

@@ -320,7 +320,7 @@ client should remember what the expiration events were for an experiment
 and honor them.
 
 The rationale here is that we want to prevent an accidental deletion
-or temporary failure on the server to inadvertantly deactivate
+or temporary failure on the server to inadvertently deactivate
 supposed-to-be-active experiments. We also don't want premature deletion
 of an experiment from the manifest to result in indefinite activation
 periods.

build/docs/defining-binaries.rst

@@ -275,7 +275,7 @@ In some cases, for convenience, it is possible to set both
 This allows to use ``mylib`` in the ``USE_LIBS`` of another library or
 executable.
 
-When refering to a ``Library`` name building both types of libraries in
+When referring to a ``Library`` name building both types of libraries in
 ``USE_LIBS``, the shared library is chosen to be linked. But sometimes,
 it is wanted to link the static version, in which case the ``Library`` name
 needs to be prefixed with ``static:`` in ``USE_LIBS``

build/docs/glossary.rst

@@ -32,7 +32,7 @@ Glossary
        A large part of the build system consists of copying files
        around to appropriate places. We write out special files
        describing the set of required operations so we can process the
-       actions effeciently. These files are install manifests.
+       actions efficiently. These files are install manifests.
 
    clobber build
       A build performed with an initially empty object directory. All

build/docs/mozinfo.rst

@@ -54,7 +54,7 @@ bits
 
    Universal Mac builds do not have this key defined.
 
-   Unkown processor architectures (see ``processor`` below) may not have
+   Unknown processor architectures (see ``processor`` below) may not have
    this key defined.
 
    Optional.

mobile/android/docs/downloadcontenttelemetry.rst

@@ -26,7 +26,7 @@ Telemetry extras sent for a successful content download might look like this:
         "content": "25610abb-5dc8-fd75-40e7-990507f010c4"
     }
 
-For failed content downloads an additional ``error`` field contains the error type that occured when downloading the content. The value can be one of:
+For failed content downloads an additional ``error`` field contains the error type that occurred when downloading the content. The value can be one of:
 
 - no_network
 - network_metered

mobile/android/docs/push.rst

@@ -125,7 +125,7 @@ registration due to inactivity or an unexpected server event.  Each
 `PushSubscription` is associated to a given *uaid* and correponds to a unique
 (per-*uaid*) *chid* (Channel ID) on the autopush server.  An individual *chid*
 is potentially long-lived, but clients must expect the service to expire *chid*s
-as part of regular maintainence.  The `PushManager` uses an `AutopushClient`
+as part of regular maintenance.  The `PushManager` uses an `AutopushClient`
 instance to interact with the autopush server.
 
 Between the `PushManager`, the `PushManagerStorage`, and assorted GCM event

mobile/android/docs/shutdown.rst

@@ -27,7 +27,7 @@ shutdown as well, so as to
 1) provide an immediate visual feedback to the user that Firefox is indeed quitting
 
 2) avoid a state where the UI is still running "normally" while the rendering engine is already
-   shutting down, which could lead to loosing incoming external tabs if they were to arrive within
+   shutting down, which could lead to losing incoming external tabs if they were to arrive within
    that period.
 
 Therefore, shutdown of the native UI was originally started simultaneously with notifying Gecko.

taskcluster/docs/cron.rst

@@ -55,4 +55,4 @@ tasks with scopes for that particular job, by name.  For example, the
     job from using any of the scopes afforded to the cron task itself (the
     ``..cron:*`` scope).  This is simply because the cron task runs arbitrary
     code from the repo, and that code can be easily modified to create tasks
-    with any scopes that it posesses.
+    with any scopes that it possesses.

taskcluster/docs/optimization.rst

@@ -31,7 +31,7 @@ Optimizing Target Tasks
 
 In some cases, such as try pushes, tasks in the target task set have been
 explicitly requested and are thus excluded from optimization. In other cases,
-the target task set is almost the entire task graph, so targetted tasks are
+the target task set is almost the entire task graph, so targeted tasks are
 considered for optimization. This behavior is controlled with the
 ``optimize_target_tasks`` parameter.
 

taskcluster/docs/parameters.rst

@@ -16,7 +16,7 @@ best to find a recent decision task's ``parameters.yml`` file, and modify that
 file if necessary, rather than starting from scratch.  This ensures you have a
 complete set of parameters.
 
-The properties of the parameters object are described here, divided rougly by
+The properties of the parameters object are described here, divided roughly by
 topic.
 
 Push Information

taskcluster/docs/taskgraph.rst

@@ -152,7 +152,7 @@ As part of the execution of the Gecko decision task we generate a
 ``public/runnable-jobs.json.gz`` file. It contains a subset of all the data
 contained within the ``full-task-graph.json``.
 
-This file has the minimum ammount of data needed by Treeherder to show all
+This file has the minimum amount of data needed by Treeherder to show all
 tasks that can be scheduled on a push.
 
 

taskcluster/docs/try.rst

@@ -2,10 +2,10 @@ Try
 ===
 
 "Try" is a way to "try out" a proposed change safely before review, without
-officialy landing it.  This functionality has been around for a *long* time in
+officially landing it.  This functionality has been around for a *long* time in
 various forms, and can sometimes show its age.
 
-Access to "push to try" is typically avilable to a much larger group of
+Access to "push to try" is typically available to a much larger group of
 developers than those who can land changes in integration and release branches.
 Specifically, try pushes are allowed for anyone with `SCM Level`_ 1, while
 integration branches are at SCM level 3.

testing/mozbase/docs/manifestparser.rst

@@ -259,12 +259,12 @@ There is a two- or three-layered approach to the manifestparser
 architecture, depending on your needs:
 
 1. ManifestParser: this is a generic parser for .ini manifests that
-facilitates the `[include:]` logic and the inheritence of
+facilitates the `[include:]` logic and the inheritance of
 metadata. Despite the internal variable being called `self.tests`
 (an oversight), this layer has nothing in particular to do with tests.
 
 2. TestManifest: this is a harness-agnostic integration layer that is
-test-specific. TestManifest faciliates `skip-if` logic.
+test-specific. TestManifest facilitates `skip-if` logic.
 
 3. Optionally, a harness will have an integration layer than inherits
 from TestManifest if more harness-specific customization is desired at

testing/mozbase/docs/mozlog.rst

@@ -190,7 +190,7 @@ harness that loads JavaScript-based tests in a browser. Each url
 loaded would be a single test, with corresponding ``test_start`` and
 ``test_end`` messages. If there can be more than one JS-defined test
 on a page, however, it it useful to track the results of those tests
-seperately. Therefore each of those tests is a subtest, and one
+separately. Therefore each of those tests is a subtest, and one
 ``test_status`` message must be generated for each subtest result.
 
 Subtests must have a name that is unique within their parent test.
@@ -401,7 +401,7 @@ More Complete Example
 ---------------------
 
 This example shows a complete toy testharness set up to used
-structured logging. It is avaliable as `structured_example.py <_static/structured_example.py>`_:
+structured logging. It is available as `structured_example.py <_static/structured_example.py>`_:
 
 .. literalinclude:: _static/structured_example.py
 

testing/mozbase/docs/mozversion.rst

@@ -60,7 +60,7 @@ Options
 '''''''''
 
 This is the path to the target application binary or .apk. If this is omitted
-then the current directory is checked for the existance of an
+then the current directory is checked for the existence of an
 application.ini file. If not found, then it is assumed the target
 application is a remote Firefox OS instance.
 
@@ -70,7 +70,7 @@ application is a remote Firefox OS instance.
 
 The path to the sources.xml that accompanies the target application (Firefox OS
 only). If this is omitted then the current directory is checked for the
-existance of a sources.xml file.
+existence of a sources.xml file.
 
 Examples
 ````````

testing/web-platform/tests/tools/wptrunner/README.rst

@@ -197,7 +197,7 @@ language e.g.::
 
   if debug and (platform == "linux" or platform == "osx"): FAIL
 
-For test expectations the avaliable variables are those in the
+For test expectations the available variables are those in the
 `run_info` which for desktop are `version`, `os`, `bits`, `processor`,
 `debug` and `product`.
 

toolkit/components/extensions/docs/events.rst

@@ -34,7 +34,7 @@ code such as:
 .. code-block:: js
 
    browser.myapi.onSomething.addListener(param1 => {
-     console.log(`Something happend: ${param1}`);
+     console.log(`Something happened: ${param1}`);
    });
 
 Note that the schema syntax looks similar to that for a function,

toolkit/components/extensions/docs/functions.rst

@@ -152,7 +152,7 @@ which can be useful while developing a new API.
 Implementing a function in a child process
 ------------------------------------------
 Most functions are implemented in the main process, but there are
-occassionally reasons to implement a function in a child process, such as:
+occasionally reasons to implement a function in a child process, such as:
 
 - The function has one or more parameters of a type that cannot be automatically
   sent to the main process using the structured clone algorithm.

toolkit/components/telemetry/docs/data/first-shutdown-ping.rst

@@ -3,7 +3,7 @@
 =====================
 
 This ping is a duplicate of the main-ping sent on first shutdown. Enabling pingsender
-for first sessions will impact existing engagment metrics. The ``first-shutdown`` ping enables a
+for first sessions will impact existing engagement metrics. The ``first-shutdown`` ping enables a
 more accurate view of users that churn after the first session. This ping exists as a
 stopgap until existing metrics are re-evaluated, allowing us to use the first session
 ``main-pings`` directly.

toolkit/components/telemetry/docs/data/main-ping.rst

@@ -469,7 +469,7 @@ Structure:
     "gc": {
       "random": [
         {
-          // "completed" or "aborted" if an OOM occured.
+          // "completed" or "aborted" if an OOM occurred.
           "status": "completed",
           // Timestamps are in milliseconds since startup. All the times here
           // are wall-clock times, which may not be monotonically increasing.

toolkit/components/telemetry/docs/data/sync-ping.rst

@@ -2,7 +2,7 @@
 "sync" ping
 ===========
 
-This is an aggregated format that contains information about each sync that occurred during a timeframe. It is submitted every 12 hours, and on browser shutdown, but only if the ``syncs`` property would not be empty. The ping does not contain the enviroment block, nor the clientId.
+This is an aggregated format that contains information about each sync that occurred during a timeframe. It is submitted every 12 hours, and on browser shutdown, but only if the ``syncs`` property would not be empty. The ping does not contain the environment block, nor the clientId.
 
 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.
 

toolkit/crashreporter/docs/index.rst

@@ -20,7 +20,7 @@ together.
 Breakpad
    Breakpad is a library and set of tools to make collecting process
    information (notably dumps from crashes) easy. Breakpad is a 3rd
-   party project (originaly developed by Google) that is imported into
+   party project (originally developed by Google) that is imported into
    the tree.
 
 Dump files

tools/lint/docs/linters/eslint-plugin-mozilla.rst

@@ -71,8 +71,8 @@ can be used instead.
 balanced-listeners
 ------------------
 
-Checks that for every occurence of 'addEventListener' or 'on' there is an
-occurence of 'removeEventListener' or 'off' with the same event name.
+Checks that for every occurrence of 'addEventListener' or 'on' there is an
+occurrence of 'removeEventListener' or 'off' with the same event name.
 
 import-browser-window-globals
 -----------------------------