--- a/browser/experiments/docs/manifest.rst
+++ b/browser/experiments/docs/manifest.rst
@@ -315,17 +315,17 @@ 2. Active experiment disappears from man
 ---------------------------------------------
 
 If a specific experiment disappears from the manifest, the client should
 continue conducting an already-active experiment. Furthermore, the
 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.
 
 3. Inactive experiment disappears from manifest
 -----------------------------------------------
 
 If an inactive but scheduled-to-be-active experiment disappears from the

--- a/build/docs/defining-binaries.rst
+++ b/build/docs/defining-binaries.rst
@@ -270,17 +270,17 @@ In some cases, for convenience, it is po
 
   Library('mylib')
   STATIC_LIBRARY_NAME = 'mylib_s'
   SHARED_LIBRARY_NAME = CONFIG['SHARED_NAME']
 
 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``
 
 ::
 
    a/moz.build:
       Library('mylib')

--- a/build/docs/glossary.rst
+++ b/build/docs/glossary.rst
@@ -27,17 +27,17 @@ Glossary
        tree. Traditionally, config.status writes out a bunch of
        Makefiles.
 
    install manifest
        A file containing metadata describing file installation rules.
        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 actions must be performed.
 
    incremental build
       A build performed with the result of a previous build in an
       object directory. The build should not have to work as hard because

--- a/build/docs/mozinfo.rst
+++ b/build/docs/mozinfo.rst
@@ -49,17 +49,17 @@ bin_suffix
 
 bits
    The number of bits in the CPU this build targets.
 
    Values are typically ``32`` or ``64``.
 
    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.
 
 buildapp
    The path to the XUL application being built.
 
    For desktop Firefox, this is ``browser``. For Fennec, it's

--- a/mobile/android/docs/downloadcontenttelemetry.rst
+++ b/mobile/android/docs/downloadcontenttelemetry.rst
@@ -21,17 +21,17 @@ Telemetry extras sent for a successful c
 .. code-block:: js
 
     extras: {
         "action": "dlc_download",
         "result": "success",
         "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
 - disk_space
 - checksum
 - io_disk
 - io_network
 - memory

--- a/mobile/android/docs/push.rst
+++ b/mobile/android/docs/push.rst
@@ -120,17 +120,17 @@ the `PushManagerStorage` to determine ho
 
 Each `PushRegistration` corresponds to a unique *uaid* (User-Agent ID) on the
 autopush server.  Each *uaid* is long-lived; a healthy client will maintain the
 same *uaid* until the client's configuration changes or the service expires the
 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
 broadcast receivers, push messages that do not target Gecko can be implemented.
 
 Gecko components
 ----------------
 

--- a/mobile/android/docs/shutdown.rst
+++ b/mobile/android/docs/shutdown.rst
@@ -22,17 +22,17 @@ Technical details
 
 When the "Quit" button is used, the UI sends a ``Browser:Quit`` notification to Gecko's ``BrowserApp``,
 which initiates the normal Gecko shutdown procedure. At the same time however, the native UI needs to
 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.
 Because the clearing of private data during shutdown is handled by Gecko's ``Sanitizer``, while some
 private data, e.g. the browsing history, is held in a database by the native UI, this means that
 Gecko needs to message the native UI during shutdown if the user wants the browsing history to be
 cleared on quitting.
 Shutting down the UI simultaneously with Gecko therefore introduced a race condition where the data

--- a/taskcluster/docs/cron.rst
+++ b/taskcluster/docs/cron.rst
@@ -50,9 +50,9 @@ tasks with scopes for that particular jo
 
 .. important::
 
     The individual cron scopes are a useful check to ensure that a job is not
     accidentally doing something it should not, but cannot actually *prevent* a
     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.

--- a/taskcluster/docs/optimization.rst
+++ b/taskcluster/docs/optimization.rst
@@ -26,17 +26,17 @@ example::
 Strategy implementations are shared across all tasks, so they may cache
 commonly-used information as instance variables.
 
 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.
 
 .. note:
 
     Because it is a mix of "what the push author wanted" and "what should run
     when necessary", try pushes with the old option syntax (``-b do -p all``,
     etc.) *do* optimize target tasks.  This can cause unexpected results when

--- a/taskcluster/docs/parameters.rst
+++ b/taskcluster/docs/parameters.rst
@@ -11,17 +11,17 @@ a full parameters file as one of its out
 taskgraph`` commands can take this file as input.  This can be very helpful
 when working on a change to the task graph.
 
 When experimenting with local runs of the task-graph generation, it is always
 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
 ----------------
 
 ``base_repository``
    The repository from which to do an initial clone, utilizing any available
    caching.

--- a/taskcluster/docs/taskgraph.rst
+++ b/taskcluster/docs/taskgraph.rst
@@ -147,17 +147,17 @@ is re-used.
 
 
 Runnable jobs
 -------------
 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.
 
 
 Task Parameterization
 ---------------------
 
 A few components of tasks are only known at the very end of the decision task
 -- just before the ``queue.createTask`` call is made.  These are specified

--- a/taskcluster/docs/try.rst
+++ b/taskcluster/docs/try.rst
@@ -1,16 +1,16 @@
 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.
 
 Scheduling a Task on Try
 ------------------------
 
 There are three methods for scheduling a task on try: legacy try option syntax,

--- a/testing/mozbase/docs/manifestparser.rst
+++ b/testing/mozbase/docs/manifestparser.rst
@@ -254,22 +254,22 @@ in their own `[DEFAULT]` section.
 
 manifestparser Architecture
 ````````````````````````````
 
 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
 the manifest level.
 
 See the source code at https://github.com/mozilla/mozbase/tree/master/manifestparser
 and
 https://github.com/mozilla/mozbase/blob/master/manifestparser/manifestparser.py

--- a/testing/mozbase/docs/mozlog.rst
+++ b/testing/mozbase/docs/mozlog.rst
@@ -185,17 +185,17 @@ Subtests
 
 The purpose of subtests is to deal with situations where a single test
 produces more than one result, and the exact details of the number of
 results is not known ahead of time. For example consider a test
 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.
 
 Whether or not a test has subtests changes the meaning of the
 ``status`` property on the test itself. When the test does not have
 any subtests, this property is the actual test result such as ``PASS``
 or ``FAIL`` . When a test does have subtests, the test itself does not
@@ -396,17 +396,17 @@ Count the number of tests that timed out
                    {"test_end": handle_test_end})
 
    print count
 
 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
 
 Each global function with a name starting
 ``test_`` represents a test. A passing test returns without
 throwing. A failing test throws a :py:class:`TestAssertion` exception
 via the :py:func:`assert_equals` function. Throwing anything else is
 considered an error in the test. There is also a :py:func:`expected`

--- a/testing/mozbase/docs/mozversion.rst
+++ b/testing/mozbase/docs/mozversion.rst
@@ -55,27 +55,27 @@ Usage::
 
 Options
 ```````
 
 ---binary
 '''''''''
 
 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.
 
 
 ---sources
 ''''''''''
 
 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
 ````````
 
 Firefox::
 
     $ mozversion --binary=/path/to/firefox-bin
     application_buildid: 20131205075310

--- a/testing/web-platform/tests/tools/wptrunner/README.rst
+++ b/testing/web-platform/tests/tools/wptrunner/README.rst
@@ -192,17 +192,17 @@ In this case each conditional is evaluat
 that on the right hand side of the first matching conditional. In the
 case that no condition matches, the unconditional default is used. If
 no condition matches and no default is provided it is equivalent to
 the key not being present. Conditionals use a simple python-like expression
 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`.
 
 Key-value pairs specified at the top level of the file before any
 sections are special as they provide defaults for the rest of the file
 e.g.::
 
   key1: value1

--- a/toolkit/components/extensions/docs/events.rst
+++ b/toolkit/components/extensions/docs/events.rst
@@ -29,17 +29,17 @@ The definition for a simple event looks 
    ]
 
 This fragment defines an event that is used from an extension with
 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,
 but for an event, the ``parameters`` property specifies the arguments
 that will be passed to a listener.
 
 Implementing an event
 ---------------------

--- a/toolkit/components/extensions/docs/functions.rst
+++ b/toolkit/components/extensions/docs/functions.rst
@@ -147,17 +147,17 @@ exposing details about the implementatio
 that is not an instance of ExtensionError is thrown, the original error
 is logged to the
 `Browser Console <https://developer.mozilla.org/en-US/docs/Tools/Browser_Console>`_,
 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.
 
 - The function implementation interacts with some part of the browser
   internals that is only accessible from a child process.
 
 - The function can be implemented substantially more efficiently in

--- a/toolkit/components/telemetry/docs/data/first-shutdown-ping.rst
+++ b/toolkit/components/telemetry/docs/data/first-shutdown-ping.rst
@@ -1,11 +1,11 @@
 
 "first-shutdown" ping
 =====================
 
 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.
 
 See :doc:`main-ping` for details about this payload.

--- a/toolkit/components/telemetry/docs/data/main-ping.rst
+++ b/toolkit/components/telemetry/docs/data/main-ping.rst
@@ -464,17 +464,17 @@ GC has a C/T probablility of being selec
 
 Structure:
 
 .. code-block:: js
 
     "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.
           "timestamp": 294872.2,
           // All durations are in milliseconds.
           "max_pause": 73.629,
           "total_time": 364.951, // Sum of all slice times.
           "zones_collected": 9,

--- a/toolkit/components/telemetry/docs/data/sync-ping.rst
+++ b/toolkit/components/telemetry/docs/data/sync-ping.rst
@@ -1,13 +1,13 @@
 
 "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.
 
 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>`_.
 
 Structure:
 
 .. code-block:: js

--- a/toolkit/crashreporter/docs/index.rst
+++ b/toolkit/crashreporter/docs/index.rst
@@ -15,17 +15,17 @@ created not only from process crashes bu
 exceptional events.
 
 The crash reporter subsystem is composed of a number of pieces working
 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
    Breakpad produces files called *dump files* that hold process data
    (stacks, heap data, etc).
 
 Crash Reporter Client
    The crash reporter client is a standalone executable that is launched

--- a/tools/lint/docs/linters/eslint-plugin-mozilla.rst
+++ b/tools/lint/docs/linters/eslint-plugin-mozilla.rst
@@ -66,18 +66,18 @@ avoid-removeChild
 -----------------
 
 Rejects using element.parentNode.removeChild(element) when element.remove()
 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
 -----------------------------
 
 For scripts included in browser-window, this will automatically inject the
 browser-window global scopes into the file.
 
 import-content-task-globals