Bug 1807901 - Fix typos in some documentation directories r=linter-reviewers,andi DONTBUILD

Fix some typos in new directories

Differential Revision: https://phabricator.services.mozilla.com/D165660

browser/components/places/docs/History.rst

@@ -28,11 +28,11 @@ A `VisitInfo` object is any object that contains A SUBSET of the following prope
 Main functions
 --------------
 
-  * Fetching. Fetch the available information for one page. You would have to specify as a string a unique identifier (Guid) or url (url, nsIURI or href). Fetching step returns a promise which is successfully resolved when fetch is completed and page is found. Throws an error when Guid or url does not have an expeected type or, if it is a string, url / Guid is not valid.
+  * Fetching. Fetch the available information for one page. You would have to specify as a string a unique identifier (Guid) or url (url, nsIURI or href). Fetching step returns a promise which is successfully resolved when fetch is completed and page is found. Throws an error when Guid or url does not have an expected type or, if it is a string, url / Guid is not valid.
 
   * Removing pages / visits from database. You would have to specify the desired page / object visit to be removed. Returns a promise which is resolved with true boolean. Throws an error when 'pages' has an unexpected type or if there are no data for provided string / filter.
 
-  * Determing if a page has been visited. Connectes with database and inquries if specified page has been visited or not. Returns a promise which is resolved with a true boolean value if page has been visited, falsy value if not. Throws an error if provided data is not a valid Guid or uri.
+  * Determining if a page has been visited. Connects with database and inquries if specified page has been visited or not. Returns a promise which is resolved with a true boolean value if page has been visited, falsy value if not. Throws an error if provided data is not a valid Guid or uri.
 
   * Clearing all history. Returns a promise which is resolved when operation is completed.
 

browser/components/places/docs/PlacesTransactions.rst

@@ -1,7 +1,7 @@
 PlacesTransactions.jsm
 ======================
 
-This module serves as the transactions manager for Places (hereinafter *PTM*). Generally, we need a transaction manager because History and Bookmark UI allows users to use `Undo / Redo` functions. To implement those transaction History and Bookmark needed to have a layer between Bookmark API and History API. This layer stores all requested changes in a stack and perform calls to API. That construction allows users perform `Undo / Redo` simply removing / adding that trasaction and call to API from an array. Inside array we store changes from oldest to newest.
+This module serves as the transactions manager for Places (hereinafter *PTM*). Generally, we need a transaction manager because History and Bookmark UI allows users to use `Undo / Redo` functions. To implement those transaction History and Bookmark needed to have a layer between Bookmark API and History API. This layer stores all requested changes in a stack and perform calls to API. That construction allows users perform `Undo / Redo` simply removing / adding that transaction and call to API from an array. Inside array we store changes from oldest to newest.
 
 Transactions implements all the elementary UI commands: creating items, editing their various properties, and so forth. All those commands stored in array and are completed one after another.
 

browser/components/places/docs/architecture-overview.rst

@@ -24,7 +24,7 @@ The frontend part of the bookmarking experience includes various kind of views:
 
 All the views share a common `Controller`_ that is responsible to handle operations and commands required by the views. Each view creates a Result object and receives notifications about changes from it.
 
-As an example, removing a bookmark from a view will call into the controller that calls into PlacesTransactions to actually do the removal. The removal will notify a `Places event`_, that is catched by the Result, that will immediately update its internal representation of the bookmarks tree. Then the Result sends a notification to the view that will handle it, updating what the user is seeing. The system works according to the classical `Model-View-Controller`_ pattern.
+As an example, removing a bookmark from a view will call into the controller that calls into PlacesTransactions to actually do the removal. The removal will notify a `Places event`_, that is caught by the Result, that will immediately update its internal representation of the bookmarks tree. Then the Result sends a notification to the view that will handle it, updating what the user is seeing. The system works according to the classical `Model-View-Controller`_ pattern.
 
 Fronted dialogs and panels are written using xhtml and shadow DOM. The bookmark dialogs in particular are wrappers around a common template, `editBookmarkPanel.inc.xhtml`_, it could be extended or overloaded like an object (overlay, similar to Web Component).
 

ipc/docs/ipdl.rst

@@ -471,7 +471,7 @@ after these descriptors are sent/received (only) in the direction specified.
 
 .. note::
     As a mnemonic to remember which direction they indicate, remember to put
-    the word "to" in front of them.  So, for example, ``parent:`` preceeds
+    the word "to" in front of them.  So, for example, ``parent:`` precedes
     ``__delete__``, meaning ``__delete__`` is sent from the child **to** the
     parent, and ``both:`` states that ``AnotherMsg`` can be sent **to** either
     endpoint.
@@ -856,7 +856,7 @@ them, determined using the type of the object as supplied.  ``WriteBytes`` and
 ``ReadBytesInto`` work on raw, contiguous bytes as expected.  ``MessageWriter``
 and ``MessageReader`` are IPDL internal objects which hold the incoming/outgoing
 message as a stream of bytes and the current spot in the stream.  It is *very*
-rare for client code to need to create or manipulate these obejcts. Their
+rare for client code to need to create or manipulate these objects. Their
 advanced use is beyond the scope of this document.
 
 .. important::
@@ -1276,7 +1276,7 @@ than to leave them in limbo until the destructor is run.
 Consider actors to be like normal reference-counted objects, but where IPDL
 holds a reference while the connection will or does exist.  One common
 architecture has IPDL holding the `only` reference to an actor.  This is common
-with actors created by sending construtor messages but the idea is available to
+with actors created by sending constructor messages but the idea is available to
 any actor.  That only reference is then released when the ``__delete__``
 message is sent or received.
 
@@ -1557,7 +1557,7 @@ On the other hand, some things we can and should control for:
 * Messages incur inherent performance overhead for a number of reasons: IPDL
   internal thread latency (e.g. the I/O thread), parameter (de-)serialization,
   etc.  While not usually dramatic, this cost can add up.  What's more, each
-  message generates a fair amound of C++ code.  For these reasons, it is wise
+  message generates a fair amount of C++ code.  For these reasons, it is wise
   to reduce the number of messages being sent as far as is reasonable.  This
   can be as simple as consolidating two asynchronous messages that are always
   in succession.  Or it can be more complex, like consolidating two
@@ -1762,5 +1762,5 @@ comma-separated list of **top-level** protocols to log (e.g.
 in tracking down a bug.
 
 .. important::
-    The preceeding ``P`` and the ``Parent`` or ``Child`` suffix are required
+    The preceding ``P`` and the ``Parent`` or ``Child`` suffix are required
     when listing individual protocols in ``MOZ_IPC_MESSAGE_LOG``.

ipc/docs/processes.rst

@@ -108,7 +108,7 @@ This diagram shows the primary process types in Firefox.
 
 The arrows point from the parent side to the child.  Bolded arrows indicate the
 first top-level actors for the various process types.  The other arrows show
-important actors that are usually the first connections establised between the
+important actors that are usually the first connections established between the
 two processes.  These relationships difficult to discern from code.  Processes
 should clearly document their top-level connections in their IPDL files.
 
@@ -156,7 +156,7 @@ Code for the complete demo can be found `here
 Common Architecture
 ~~~~~~~~~~~~~~~~~~~
 
-Every type of process (besides the launcher and main processses) needs two
+Every type of process (besides the launcher and main processes) needs two
 classes and an actor pair to launch.  This sample will be adding a process type
 we call **Demo**.
 
@@ -645,7 +645,7 @@ exists as long as the ``ProcessChild`` does -- although the message channel may
 be closed.  We will release the reference either when the process is properly
 shutting down or when an IPC error closes the channel.
 
-``Init`` is given the command line arguments constucted above so it will need
+``Init`` is given the command line arguments constructed above so it will need
 to be overridden to parse them.  It does this, binds our actor by
 calling ``Bind`` as was done with the parent, then initializes a bunch of
 components that the process expects to use:
@@ -713,7 +713,7 @@ Destroying the New Process
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Gecko processes have a clean way for clients to request that they shutdown.
-Simply calling ``Close()`` on the top level actor at either endoint will begin
+Simply calling ``Close()`` on the top level actor at either endpoint will begin
 the shutdown procedure (so, ``PDemoParent::Close`` or ``PDemoChild::Close``).
 The only other way for a child process to terminate is to crash.  Each of these
 three options requires some special handling.
@@ -1211,7 +1211,7 @@ Set ``MOZ_DEBUG_CHILD_PROCESS=1`` to turn on process startup pausing.  You can
 also set ``MOZ_DEBUG_CHILD_PAUSE=N`` where N is the number of seconds to sleep.
 The default is 10 seconds on Windows and 30 on other platforms.
 
-Pausing for the debugger is not a panacea.  Since the environmental varaiables
+Pausing for the debugger is not a panacea.  Since the environmental variables
 are not specific to process type, you will be forced to wait for all of the
 processes Gecko creates before you wait for it to get to yours.  The pauses can
 also end up exposing unknown concurrency bugs in the browser before it even

python/mozperftest/perfdocs/developing.rst

@@ -32,7 +32,7 @@ runs them sequentially.
 The goal of this organization is to allow adding new performance tests runners
 that will be based on a specific combination of layers. To avoid messy code,
 we need to make sure that each layer represents a single aspect of the process
-and that is completely independant from other layers (besides sharing the data
+and that is completely independent from other layers (besides sharing the data
 through the common environment.)
 
 For instance, we could use `perftest` to run a C++ benchmark by implementing a

python/mozperftest/perfdocs/running.rst

@@ -15,7 +15,7 @@ The `mach` command will bootstrap the installation of all required tools for the
 framework to run, and display a selection screen to pick a test. Once the
 selection is done, the performance test will run locally.
 
-If you know what test you want to run, you can use its path explicitely::
+If you know what test you want to run, you can use its path explicitly::
 
     $ ./mach perftest perftest_script.js
 

python/mozperftest/perfdocs/writing.rst

@@ -145,9 +145,9 @@ A Python module can be used to run functions during a run lifecycle. Available h
   change the running environment.
 - **after_runs(env)** runs after the test is done.
 - **on_exception(env, layer, exception)** called on any exception. Provides the
-  layer in which the exception occured, and the exception. If the hook returns `True`
+  layer in which the exception occurred, and the exception. If the hook returns `True`
   the exception is ignored and the test resumes. If the hook returns `False`, the
-  exception is ignored and the test ends immediatly. The hook can also re-raise the
+  exception is ignored and the test ends immediately. The hook can also re-raise the
   exception or raise its own exception.
 
 In the example below, the `before_runs` hook is setting the options on the fly,

services/settings/docs/index.rst

@@ -320,7 +320,7 @@ The polling for changes process sends two notifications that observers can regis
 
 * ``remote-settings:changes-poll-start``: Polling for changes is starting. triggered either by the scheduled timer or a push broadcast.
 * ``remote-settings:changes-poll-end``: Polling for changes has ended
-* ``remote-settings:sync-error``: A synchronization error occured. Notification subject provides information about the error and affected
+* ``remote-settings:sync-error``: A synchronization error occurred. Notification subject provides information about the error and affected
   collection in the ``wrappedJSObject`` attribute.
 * ``remote-settings:broken-sync-error``: Synchronization seems to be consistently failing. Profile is at risk.
 

testing/docs/xpcshell/index.rst

@@ -287,7 +287,7 @@ xpcshell.ini manifest
 
 The manifest controls what tests are included in a test suite, and the
 configuration of the tests. It is loaded via the \`moz.build\` property
-configuration proprety.
+configuration property.
 
 The following are all of the configuration options for a test suite as
 listed under the ``[DEFAULT]`` section of the manifest.
@@ -534,7 +534,7 @@ Runtime detection
 Some tests will want to only execute certain portions on specific
 platforms. Use
 `AppConstants.jsm <https://searchfox.org/mozilla-central/rev/a0333927deabfe980094a14d0549b589f34cbe49/toolkit/modules/AppConstants.jsm#148>`__
-for determing the platform, for example:
+for determining the platform, for example:
 
 .. code:: brush:
 

testing/perfdocs/generated/browsertime.rst

@@ -28,7 +28,7 @@ Vanilla Browsertime tests
 
 If you want to run highly customized tests, you can make use of our customizable ``browsertime`` test.
 
-With this test, you can customize the page to test, test script to use, and anything else required. It will make use of default settings that Raptor uses in browsertime but these can be overriden with ``--browsertime-arg`` settings.
+With this test, you can customize the page to test, test script to use, and anything else required. It will make use of default settings that Raptor uses in browsertime but these can be overridden with ``--browsertime-arg`` settings.
 
 For example, here's a test on ``https://www.sitespeed.io`` using this custom test:
 
@@ -205,7 +205,7 @@ Mach Browsertime Setup
 ----------------------
 
 **WARNING**
- Raptor-Browsertime (i.e. ``./mach raptor --browsertime -t <TEST>``) is currently required to be ran first in order to acquire the Node-16 binary. In general, it is also not reccomended to use ``./mach browsertime`` for testing as it will be deprecated soon.
+ Raptor-Browsertime (i.e. ``./mach raptor --browsertime -t <TEST>``) is currently required to be ran first in order to acquire the Node-16 binary. In general, it is also not recommended to use ``./mach browsertime`` for testing as it will be deprecated soon.
 
 Note that if you are running Raptor-Browsertime then it will get installed automatically and also update itself. Otherwise, you can run:
 

testing/perfdocs/generated/developing.rst

@@ -32,7 +32,7 @@ runs them sequentially.
 The goal of this organization is to allow adding new performance tests runners
 that will be based on a specific combination of layers. To avoid messy code,
 we need to make sure that each layer represents a single aspect of the process
-and that is completely independant from other layers (besides sharing the data
+and that is completely independent from other layers (besides sharing the data
 through the common environment.)
 
 For instance, we could use `perftest` to run a C++ benchmark by implementing a

testing/perfdocs/generated/metrics.rst

@@ -20,7 +20,7 @@ Below, you can find the process of how we run Warm, Cold, and Chimera pageload t
 Warm Pageload
 ==============
 
-In this pageload test type, we open the browser, then repeatedly navigate to the same page without restarting the brower in between cycles.
+In this pageload test type, we open the browser, then repeatedly navigate to the same page without restarting the browser in between cycles.
 
 * A new, or conditioned, browser profile is created
 * The browser is started up

testing/perfdocs/generated/running.rst

@@ -15,7 +15,7 @@ The `mach` command will bootstrap the installation of all required tools for the
 framework to run, and display a selection screen to pick a test. Once the
 selection is done, the performance test will run locally.
 
-If you know what test you want to run, you can use its path explicitely::
+If you know what test you want to run, you can use its path explicitly::
 
     $ ./mach perftest perftest_script.js
 

testing/perfdocs/generated/writing.rst

@@ -145,9 +145,9 @@ A Python module can be used to run functions during a run lifecycle. Available h
   change the running environment.
 - **after_runs(env)** runs after the test is done.
 - **on_exception(env, layer, exception)** called on any exception. Provides the
-  layer in which the exception occured, and the exception. If the hook returns `True`
+  layer in which the exception occurred, and the exception. If the hook returns `True`
   the exception is ignored and the test resumes. If the hook returns `False`, the
-  exception is ignored and the test ends immediatly. The hook can also re-raise the
+  exception is ignored and the test ends immediately. The hook can also re-raise the
   exception or raise its own exception.
 
 In the example below, the `before_runs` hook is setting the options on the fly,

testing/raptor/raptor/perfdocs/browsertime.rst

@@ -28,7 +28,7 @@ Vanilla Browsertime tests
 
 If you want to run highly customized tests, you can make use of our customizable ``browsertime`` test.
 
-With this test, you can customize the page to test, test script to use, and anything else required. It will make use of default settings that Raptor uses in browsertime but these can be overriden with ``--browsertime-arg`` settings.
+With this test, you can customize the page to test, test script to use, and anything else required. It will make use of default settings that Raptor uses in browsertime but these can be overridden with ``--browsertime-arg`` settings.
 
 For example, here's a test on ``https://www.sitespeed.io`` using this custom test:
 
@@ -205,7 +205,7 @@ Mach Browsertime Setup
 ----------------------
 
 **WARNING**
- Raptor-Browsertime (i.e. ``./mach raptor --browsertime -t <TEST>``) is currently required to be ran first in order to acquire the Node-16 binary. In general, it is also not reccomended to use ``./mach browsertime`` for testing as it will be deprecated soon.
+ Raptor-Browsertime (i.e. ``./mach raptor --browsertime -t <TEST>``) is currently required to be ran first in order to acquire the Node-16 binary. In general, it is also not recommended to use ``./mach browsertime`` for testing as it will be deprecated soon.
 
 Note that if you are running Raptor-Browsertime then it will get installed automatically and also update itself. Otherwise, you can run:
 

testing/raptor/raptor/perfdocs/metrics.rst

@@ -20,7 +20,7 @@ Below, you can find the process of how we run Warm, Cold, and Chimera pageload t
 Warm Pageload
 ==============
 
-In this pageload test type, we open the browser, then repeatedly navigate to the same page without restarting the brower in between cycles.
+In this pageload test type, we open the browser, then repeatedly navigate to the same page without restarting the browser in between cycles.
 
 * A new, or conditioned, browser profile is created
 * The browser is started up

tools/profiler/docs/code-overview.rst

@@ -1144,7 +1144,7 @@ elements, etc.), and calls back into a provided
 `JSONWriteFunc interface <https://searchfox.org/mozilla-central/search?q=symbol:T_mozilla%3A%3AJSONWriteFunc>`_
 to output characters.
 
-While these clases live outside of the Profiler directories, it may sometimes be
+While these classes live outside of the Profiler directories, it may sometimes be
 worth maintaining and/or modifying them to better serve the Profiler's needs.
 But there are other users, so be careful not to break other things!
 

xpcom/docs/collections.rst

@@ -11,7 +11,7 @@ Rust Bindings
 
 When the ``thin_vec`` crate is built in Gecko, ``thin_vec::ThinVec<T>`` is
 guaranteed to have the same memory layout and allocation strategy as
-``nsTArray``, meaning that the two types may be used interchangably across
+``nsTArray``, meaning that the two types may be used interchangeably across
 FFI boundaries. The type is **not** safe to pass by-value over FFI
 boundaries, due to Rust and C++ differing in when they run destructors.
 

xpcom/docs/huntingleaks.rst

@@ -5,7 +5,7 @@ Hunting Leaks
     :local:
     :depth: 2
 
-Different tools and technics are used to hunt leaks:
+Different tools and techniques are used to hunt leaks:
 
 .. list-table::
    :header-rows: 1

xpcom/docs/logging.rst

@@ -32,8 +32,8 @@ When a log statement is logged on a thread and the `Firefox Profiler
 recorded as a profiler marker.
 
 This allows getting logs alongside profiler markers and lots of performance
-and contextual informations, in a way that doesn't require disabling the
-sandbox, and works accross all processes.
+and contextual information, in a way that doesn't require disabling the
+sandbox, and works across all processes.
 
 The profile can be downloaded and shared e.g. via Bugzilla or email, or
 uploaded, and the logging statements will be visible either in the marker chart

xpcom/docs/stringguide.rst

@@ -68,7 +68,7 @@ There are a number of additional string classes:
 * ``nsLiteral[C]String`` which should rarely be constructed explicitly but
   usually through the ``""_ns`` and ``u""_ns`` user-defined string literals.
   ``nsLiteral[C]String`` is trivially constructible and destructible, and
-  therefore does not emit construction/destruction code when stored in statics,
+  therefore does not emit construction/destruction code when stored in static,
   as opposed to the other string classes.
 
 The Major String Classes
@@ -334,7 +334,7 @@ indicate success or OOM. Calling ``RestartBulkWrite()`` invalidates
 previously-obtained span, raw pointer or length.
 
 Once you are done writing, call ``Finish()``. It takes two arguments: the new
-logical length of the string (which must not exceed the capacity retuned by
+logical length of the string (which must not exceed the capacity returned by
 the ``Length()`` method of the handle) and a boolean indicating whether it's
 OK to attempt to reallocate a smaller buffer in case a smaller mozjemalloc
 bucket could accommodate the new logical length.
@@ -462,7 +462,7 @@ ones are defined in the `Encoding Standard <https://encoding.spec.whatwg.org/>`_
 Conversions from these encodings to
 UTF-8 and UTF-16 are provided by `mozilla::Encoding
 <https://searchfox.org/mozilla-central/source/intl/Encoding.h#109>`_.
-Additonally, on Windows the are some rare cases (e.g. drag&drop) where it's
+Additionally, on Windows the are some rare cases (e.g. drag&drop) where it's
 necessary to call a system API with data encoded in the Windows
 locale-dependent legacy encoding instead of UTF-16. In those rare cases, use
 ``MultiByteToWideChar``/``WideCharToMultiByte`` from kernel32.dll. Do not use
@@ -655,7 +655,7 @@ deal with response bodies.)
 
 .. cpp:function:: NS_ConvertASCIItoUTF16(const nsACString&)
 
-    A ``nsAutoString`` which holds a temproary buffer contianing the value of
+    A ``nsAutoString`` which holds a temporary buffer containing the value of
     the Latin1 to UTF-16 conversion.
 
 .. cpp:function:: void CopyASCIItoUTF16(Span<const char>, nsAString&)

xpcom/docs/writing-xpcom-interface.rst

@@ -140,7 +140,7 @@ Now write the header: :code:`path/to/ComponentName.h`
       // This second macro includes the declarations for the attributes. There is
       // no need to duplicate these declarations.
       //
-      // In our case it includes a declaration for the isAlive attribue:
+      // In our case it includes a declaration for the isAlive attribute:
       //   GetIsAlive(bool *aIsAlive)
       NS_DECL_NSICOMPONENTNAME
 

xpcom/docs/xpidl.rst

@@ -139,7 +139,7 @@ an array element.
 Constants and CEnums
 ~~~~~~~~~~~~~~~~~~~~
 
-Constants must be attched to an interface. The only constants supported are
+Constants must be attached to an interface. The only constants supported are
 those which become integer types when compiled to source code; string constants
 and floating point constants are currently not supported.