Bug 1523092 - Enable codespell on more directories r=ahal
authorSylvestre Ledru <sledru@mozilla.com>
Wed, 30 Jan 2019 14:16:08 +0000
changeset 456057 7271b047bfa63918e0a42d370fabafc63f12d869
parent 456056 65509fbdbc55b5257dea5b6b78b0e8af21a9b40a
child 456058 edf04064498b34d79a8052bf606a9726388abc42
push id35468
push userrgurzau@mozilla.com
push dateWed, 30 Jan 2019 17:02:03 +0000
treeherdermozilla-central@37103bfa3dca [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersahal
bugs1523092
milestone67.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1523092 - Enable codespell on more directories r=ahal Differential Revision: https://phabricator.services.mozilla.com/D17740
browser/components/newtab/docs/v2-system-addon/snippets.md
browser/components/newtab/docs/v2-system-addon/telemetry.md
browser/components/newtab/docs/v2-system-addon/tippytop.md
browser/components/newtab/docs/v2-system-addon/unit_testing_guide.md
browser/installer/windows/docs/Helper.rst
browser/installer/windows/docs/StubConfig.rst
devtools/docs/backend/client-api.md
devtools/docs/backend/protocol.js.md
devtools/docs/backend/protocol.md
devtools/docs/contributing/react-performance-tips.md
devtools/docs/frontend/telemetry.md
devtools/docs/preferences.md
js/src/doc/Debugger/Debugger.Script.md
js/src/doc/Debugger/Debugger.Source.md
toolkit/components/normandy/docs/data-collection.rst
tools/lint/codespell.yml
tools/lint/spell/exclude-list.txt
--- a/browser/components/newtab/docs/v2-system-addon/snippets.md
+++ b/browser/components/newtab/docs/v2-system-addon/snippets.md
@@ -40,17 +40,17 @@ a Promise that resolves when the blockLi
 You should ensure `gSnippetsMap.get("appData.onboardingFinished")` is false before calling this. Note that this
 does not hide onboarding notifications on the **current** page, since that would be a disruptive user experience.
 
 `.getTotalBookmarksCount()`: (func) An async function that resolves with an integer representing the number of
 bookmarks a user has (including default bookmarks). Note that is value is only updated once per day or when a
 a user restarts the browser.
 
 `.getAddonsInfo()`:( func) An async function that resolves with an object `{isFullData: (bool), addons: (obj)}`.
-Note that at startup, we are sometimes unable to provide full data due to performance constraits (`.isFullData` will be `false`).
+Note that at startup, we are sometimes unable to provide full data due to performance constraints (`.isFullData` will be `false`).
 E.g.
 
 ```js
 {
   isFullData: true,
   addons: {
       // This is the ID of the addon
     "someaddon@mozilla.org": {
--- a/browser/components/newtab/docs/v2-system-addon/telemetry.md
+++ b/browser/components/newtab/docs/v2-system-addon/telemetry.md
@@ -7,13 +7,13 @@ 1. - [ ] File a "user story issue" [in p
     > As an engineer, I see the distribution of times between triggering a new tab load by tab menu entry, plus button or keyboard shortcut and when the visibility event is fired on that page, so that I can understand how long it takes before the page becomes visible and how close to instantaneous that feels.
 
 1. - [ ] File or update your existing client-side implementation bug so that it points to the "user story issue".
 1. - [ ] Talk to Marina (@emtwo) about the dashboard you're hoping to see from the data you're adding, and work with her to create a data model (or request her review on it after the fact).
 1. - [ ] Update `system-addon/test/schemas/pings.js` with a commented JOI schema of your changes, and add tests to system-addon/test/unit/TelemetryFeed.test.js to exercise the ping creation.
 1. - [ ] Update [data_events.md](data_events.md) with an example of the data in question
 1. - [ ] Update any fields that you've added, deleted, or changed in [data_dictionary.md](data_dictionary.md)
 1. - [ ] Get review from Nan (@ncloudioj) and/or Marina (@emtwo) on the data schema and the documentation changes.
-1. - [ ] Request `data-review` of your documentation changes from a [data steward](https://wiki.mozilla.org/Firefox/Data_Collection) to ensure suitability for collection controlled by the opt-out `datareporting.healthreport.uploadEnabled` pref. Download and fill out the [data review request form](https://github.com/mozilla/data-review/blob/master/request.md) and then attach it as a text file on Bugzilla so you can r? a data steward. We've been working with Fran├žois Marier (:francois / @fmarier), so he's a good candidate as he's likely to have the most context.
+1. - [ ] Request `data-review` of your documentation changes from a [data steward](https://wiki.mozilla.org/Firefox/Data_Collection) to ensure suitability for collection controlled by the opt-out `datareporting.healthreport.uploadEnabled` pref. Download and fill out the [data review request form](https://github.com/mozilla/data-review/blob/master/request.md) and then attach it as a text file on Bugzilla so you can r? a data steward. We've been working with Francois Marier (:francois / @fmarier), so he's a good candidate as he's likely to have the most context.
 1. - [ ] Implement as usual...
 1. - [ ] After landing the implementation, check with Nan (@ncloudioj) to make sure the pings are making it to the database
 1. - [ ] Update the [ping-centre](https://github.com/mozilla/ping-centre/issues) user story issue for the dashboard, stating that the data should now be available for implementation, and removing any `blocked` tag if appropriate.
 
--- a/browser/components/newtab/docs/v2-system-addon/tippytop.md
+++ b/browser/components/newtab/docs/v2-system-addon/tippytop.md
@@ -1,16 +1,16 @@
 # TippyTop in Activity Stream
 TippyTop, a collection of icons from the Alexa top sites, provides high quality images for the Top Sites in Activity Stream. The TippyTop manifest is hosted on S3, and then moved to [Remote Settings](https://firefox-source-docs.mozilla.org/services/common/docs/services/RemoteSettings.html) since Firefox 63. In this document, we'll cover how we produce and manage TippyTop manifest for Activity Stream.
 
 ## TippyTop manifest production
 TippyTop manifest is produced by [tippy-top-sites](https://github.com/mozilla/tippy-top-sites).
 
 ```sh
-# set up the enviroment, only needed for the first time
+# set up the environment, only needed for the first time
 $ pip install -r requirements.txt
 $ python make_manifest.py --count 2000 > icons.json  # Alexa top 2000 sites
 ```
 
 Because the manifest is hosted remotely, we use another repo [tippytop-service](https://github.com/mozilla-services/tippytop-service) for the version control and deployment. Ask :nanj or :r1cky for permission to access this private repo.
 
 ## TippyTop manifest publishing
 For each new manifest release, firstly you should tag it in the tippytop-service repo, then publish it as follows:
@@ -31,10 +31,10 @@ To publish the manifest to Remote Settin
 # publish it to prod
 $ source .venv/bin/activate
 # It will ask you for your LDAP user name and password.
 $ ./upload2remotesettings.py prod
 ```
 
 After uploading it to Remote Setting, you can request for review in the [dashboard](https://settings-writer.prod.mozaws.net/v1/admin/). Note that you will need to log in the Mozilla LDAP VPN for both uploading and accessing Remote Setting's dashboard. Once your request gets approved by the reviewer, the new manifest will be content signed and published to production.
 
-## TippyTop Viwer
-You can use this [viwer](https://mozilla.github.io/tippy-top-sites/manifest-viewer/) to load all the icons in the current manifest.
+## TippyTop Viewer
+You can use this [viewer](https://mozilla.github.io/tippy-top-sites/manifest-viewer/) to load all the icons in the current manifest.
--- a/browser/components/newtab/docs/v2-system-addon/unit_testing_guide.md
+++ b/browser/components/newtab/docs/v2-system-addon/unit_testing_guide.md
@@ -12,17 +12,17 @@ You can find unit tests in `system-addon
 
 To run the unit tests once, run `npm run testmc`.
 
 To run unit tests continuously (i.e. in "test-driven development" mode), you can
 run `npm run tddmc`.
 
 ## Debugging tests
 
-To debug tests, you should run them in continous mode with `npm run tddmc`. In the
+To debug tests, you should run them in continuous mode with `npm run tddmc`. In the
 Firefox window that is opened (it should say "Karma... - connected"), click the
 "debug" button and open your console to see test output, set breakpoints, etc.
 
 Unfortunately, source maps for tests do not currently work in Firefox. If you need
 to see line numbers, you can run the tests with Chrome by running
 `npm run tddmc -- --browsers Chrome`
 
 ## Where to put new tests
--- a/browser/installer/windows/docs/Helper.rst
+++ b/browser/installer/windows/docs/Helper.rst
@@ -8,17 +8,17 @@ Uninstaller
 The uninstaller may be the most straightforward of the installer components. The only complexity comes from a need to avoid accidentally removing any user files that may have found their way into the installation directory; the general philosophy of the uninstaller is to remove everything that the installer creates, and nothing that it doesn't.
 
 First, any registry entries the installer would have created are removed, even ones only used by very old installer versions. Then all the files that the uninstaller knows were created by the installer or are owned by the application are deleted, or flagged for deletion on reboot if any are in use. There are a few hard-coded directories that are known to be safe to delete (for example, the distribution directory, and any temporary directories created by the updater). For a list of application files that are safe to uninstall, we read a file from the application directory called ``precomplete``. This file is mainly used to tell the updater what it should do to clean out the directory when applying a complete update (one that replaces all application files), but that means it contains a handy auto-generated list of all application files, so it can be reused for uninstallation. If the application directory is empty after that, then it is removed, but it's left alone if any files are still present. Finally, if the copy of Firefox that was just uninstalled is the only one that was using the maintenance service, the maintenance service uninstaller is also run.
 
 Note that profiles and any other user-generated files (e.g., crash reports) are specifically not uninstalled.
 
 PostUpdate
 ----------
-At the end of an application update cycle, after the new files are in place, the updater invokes the helper with the ``/PostUpdate`` command-line switch. The PostUpdate function fills a grab bag of responsibilities which are all focused around maintaining system integration objects created by the installer. For example, a number of registry entires contain the version number, so that has to be changed on updates. If the branding name of the application changes and shortcuts have to be renamed, that's done here as well. For one counterexample, changing icons does not require any code in PostUpdate, or anywhere else; new icons are automatically picked up by the shell. The PostUpdate function also keeps the maintenance service up to date.
+At the end of an application update cycle, after the new files are in place, the updater invokes the helper with the ``/PostUpdate`` command-line switch. The PostUpdate function fills a grab bag of responsibilities which are all focused around maintaining system integration objects created by the installer. For example, a number of registry entries contain the version number, so that has to be changed on updates. If the branding name of the application changes and shortcuts have to be renamed, that's done here as well. For one counterexample, changing icons does not require any code in PostUpdate, or anywhere else; new icons are automatically picked up by the shell. The PostUpdate function also keeps the maintenance service up to date.
 
 It's important to remember that PostUpdate is, indeed, post-update. It doesn't run until after its own code has already been updated. This makes it really the only phase of the update process where changes can go into affect immediately in the first build that contains a patch, instead of having to wait for the next update after that. This makes it a good place to put anything that needs to be done before the new version of the application can run; this includes things like registering DLL's, which the installer also handles, but that PostUpdate has to take care of for existing installations.
 
 It's also important to remember that PostUpdate, being part of the installer code, only exists on Windows, so it can't be used to fix things up on other platforms the same way.
 
 Default Browser and Shortcut Handling
 -------------------------------------
 Windows versions older than 10 contain a control panel called Set Program Access and Defaults, or SPAD. As the name suggests, this was the UI for setting default programs for classes of activities ("web browser" or "e-mail client" for example), as the Windows 10 default program settings page is, but it also controls program "access," which is typically defined as whether or not shortcuts for the program exist. To support this interface, an application has to register a set of commands that the interface can invoke to hide or show the shortcuts, and to have the application make itself the default. We implement these actions in helper.exe; they're triggered by invoking it with the command-line switches ``/ShowShortcuts``, ``/HideShortcuts``, or ``/SetAsDefaultAppGlobal``.
--- a/browser/installer/windows/docs/StubConfig.rst
+++ b/browser/installer/windows/docs/StubConfig.rst
@@ -11,17 +11,17 @@ The stub installer automatically selects
 1. The operating system is a 64-bit build.
 2. The system has enough physical memory installed. Currently an amount strictly greater than 2 GB is required (that is, exactly 2 GB is not considered enough).
 3. No third-party software that is incompatible with the 64-bit build is present on the system.
 
 If any of the above conditions is not satisfied, a 32-bit build is installed.
 
 Scope
 -----
-We support creating the installation in either a machine or a per-user scope. This affects whether application files, shortcuts, and registry entires are created in locations that are accessible to any user on the machine or locations that are specific to a particular user. Even in the full installer there is no UI for configuring which scope is selected; instead both installers automatically select a scope based on whether they have the privileges needed to perform a machine scope installation. This means a user with those privileges can effectively control the scope by the selection they make in the Windows UAC prompt; rejecting it will mean that the installer doesn't see that user as an administrator and will perform a per-user installation.
+We support creating the installation in either a machine or a per-user scope. This affects whether application files, shortcuts, and registry entries are created in locations that are accessible to any user on the machine or locations that are specific to a particular user. Even in the full installer there is no UI for configuring which scope is selected; instead both installers automatically select a scope based on whether they have the privileges needed to perform a machine scope installation. This means a user with those privileges can effectively control the scope by the selection they make in the Windows UAC prompt; rejecting it will mean that the installer doesn't see that user as an administrator and will perform a per-user installation.
 
 Install Location
 ----------------
 The user doesn't have any control over the install location used by the stub. To determine the location that will be used, first the stub looks for any existing installations of the same channel of Firefox. If it finds one of those and the architecture of that installation is the same as the one that's been selected for the new one, then the path for the new install will be set to the same as that install, effectively overwriting it. This allows the stub to be used as a repair method for broken installations. If there isn't any existing installation fitting those criteria, then a hard-coded default is selected based on the architecture, scope, and channel.
 
 Profile Cleanup
 ---------------
 If the stub installer detects that this could be a helpful thing to do, it will start off the installation by offering to clean up the user's Firefox profile. This is the same cleanup that's triggered by the "refresh" button in about:support, and it's performed by the same Firefox code (the stub really just asks the browser to do the cleanup using a command-line parameter, it doesn't try to perform the operation itself). The user can control whether this cleanup is done by toggling a checkbox that's shown before the installation begins.
--- a/devtools/docs/backend/client-api.md
+++ b/devtools/docs/backend/client-api.md
@@ -17,17 +17,17 @@ function start() {
 
   // Listen to an nsIPipe
   let transport = DebuggerServer.connectPipe();
 
   // Start the client.
   client = new DebuggerClient(transport);
 
   client.connect((type, traits) => {
-    // Now the client is conected to the server.
+    // Now the client is connected to the server.
     debugTab();
   });
 }
 ```
 
 If a TCP socket is required, the function should be split in two parts, a server-side and a client-side, like this:
 
 ```javascript
@@ -45,17 +45,17 @@ function startServer() {
 
 async function startClient() {
   let transport = await DebuggerClient.socketConnect({ host: "localhost", port: 2929 });
 
   // Start the client.
   client = new DebuggerClient(transport);
 
   client.connect((type, traits) => {
-    // Now the client is conected to the server.
+    // Now the client is connected to the server.
     debugTab();
   });
 }
 ```
 
 ## Shutting down
 
 When the application is finished, it has to notify the client to shut down the protocol connection. This makes sure that memory leaks are avoided and the server is terminated in an orderly fashion. Shutting down is as simple as it gets:
@@ -159,17 +159,17 @@ function startDebugger() {
   // For an nsIServerSocket we do this:
   // DebuggerServer.openListener(port);
   // ...and this at the client:
   // let transport = debuggerSocketConnect(host, port);
 
   // Start the client.
   client = new DebuggerClient(transport);
   client.connect((type, traits) => {
-    // Now the client is conected to the server.
+    // Now the client is connected to the server.
     debugTab();
   });
 }
 
 function shutdownDebugger() {
   client.close();
 }
 
--- a/devtools/docs/backend/protocol.js.md
+++ b/devtools/docs/backend/protocol.js.md
@@ -477,17 +477,17 @@ Now you can listen to events on a front:
     front.giveGoodNews().then(() => { console.log("request returned.") });
 
 You might want to update your front's state when an event is fired, before emitting it against the front.  You can use `preEvent` in the front definition for that:
 
     countGoodNews: protocol.preEvent("good-news", function (news) {
         this.amountOfGoodNews++;
     });
 
-You can have events wait until an asynchronous action completes before firing by returning a promise. If you have multiple preEvents defined for a specific event, and atleast one fires asynchronously, then all preEvents most resolve before all events are fired.
+You can have events wait until an asynchronous action completes before firing by returning a promise. If you have multiple preEvents defined for a specific event, and at least one fires asynchronously, then all preEvents most resolve before all events are fired.
 
     countGoodNews: protocol.preEvent("good-news", function (news) {
         return this.updateGoodNews().then(() => this.amountOfGoodNews++);
     });
 
 On a somewhat related note, not every method needs to be request/response.  Just like an actor can emit a one-way event, a method can be marked as a one-way request.  Maybe we don't care about giveGoodNews returning anything:
 
     // spec:
@@ -558,17 +558,17 @@ You can customize this behavior in two w
       }
     }
 
     // implementation:
     getSibling: function (id) {
       return new ChildActor(this.conn, id);
     }
 
-This creates a new child actor owned by the current child actor.  But in this example we want all actors created by the child to be owned by the HelloActor.  So we can define a `defaultParent` property that makes use of the `parent` proeprty provided by the Actor class:
+This creates a new child actor owned by the current child actor.  But in this example we want all actors created by the child to be owned by the HelloActor.  So we can define a `defaultParent` property that makes use of the `parent` property provided by the Actor class:
 
     get marshallPool() { return this.parent }
 
 The front needs to provide a matching `defaultParent` property that returns an owning front, to make sure the client and server lifetimes stay synced.
 
 For more complex situations, you can define your own lifetime properties.  Take this new pair of HelloActor methods:
 
     // When the "temp" lifetime is specified, look for the _temporaryParent attribute as the owner.
--- a/devtools/docs/backend/protocol.md
+++ b/devtools/docs/backend/protocol.md
@@ -96,25 +96,25 @@ where *name* is a JSON string naming wha
 If an actor receives a packet whose type it does not recognize, it sends an error reply of the form:
 
 ```
 { "from":actor, "error":"unrecognizedPacketType", "message":message }
 ```
 
 where *message* provides details to help debugger developers understand what went wrong: what kind of actor actor is; the packet received; and so on.
 
-If an actor recieves a packet which is missing needed parameters (say, a `"releaseMany"` packet with no `"actors"` parameter), it sends an error reply of the form:
+If an actor receives a packet which is missing needed parameters (say, a `"releaseMany"` packet with no `"actors"` parameter), it sends an error reply of the form:
 
 ```
 { "from":actor, "error":"missingParameter", "message":message }
 ```
 
 where *message* provides details to help debugger developers fix the problem.
 
-If an actor recieves a packet with a parameter whose value is inappropriate for the operation, it sends an error reply of the form:
+If an actor receives a packet with a parameter whose value is inappropriate for the operation, it sends an error reply of the form:
 
 ```
 { "from":actor, "error":"badParameterType", "message":message }
 ```
 
 where *message* provides details to help debugger developers fix the problem. (Some packets' descriptions specify more specific errors for particular circumstances.)
 
 ### Grips
@@ -743,17 +743,17 @@ A thread is always in one of the followi
 
 * **Exited**: the thread has ceased execution, and will disappear. The resources of the underlying thread may have been freed; this state merely indicates that the actor's name is not yet available for reuse. When the actor receives a "release" packet, the name may be reused.
 
 ![Thread states](../resources/thread-states.png)
 
 These interactions are meant to have certain properties:
 
 * At no point may either client or server send an unbounded number of packets without receiving a packet from its counterpart. This avoids deadlock without requiring either side to buffer an arbitrary number of packets per actor.
-* In states where a transition can be initiated by either the debugger or the thread, it is always clear to the debugger which state the thread actually entered, and for what reason.<br>For example, if the debugger interrupts a running thread, it cannot be sure whether the thread stopped because of the interruption, paused of its own accord (to report a watchpoint hit, say), or exited. However, the next packet the debugger receives will either be "paused", or "exited", resolving the ambiguity.<br>Similarly, when the debugger attaches to a thread, it cannot be sure whether it has succeeded in attaching to the thread, or whether the thread exited before the "attach" packet arrived. However, in either case the debugger can expect a disambiguating response: if the attach suceeded, it receives an "attached" packet; and in the second case, it receives an "exit" packet.<br>To support this property, the thread ignores certain debugger packets in some states (the "interrupt" packet in the **Paused** and **Exited** states, for example). These cases all handle situations where the ignored packet was preempted by some thread action.
+* In states where a transition can be initiated by either the debugger or the thread, it is always clear to the debugger which state the thread actually entered, and for what reason.<br>For example, if the debugger interrupts a running thread, it cannot be sure whether the thread stopped because of the interruption, paused of its own accord (to report a watchpoint hit, say), or exited. However, the next packet the debugger receives will either be "paused", or "exited", resolving the ambiguity.<br>Similarly, when the debugger attaches to a thread, it cannot be sure whether it has succeeded in attaching to the thread, or whether the thread exited before the "attach" packet arrived. However, in either case the debugger can expect a disambiguating response: if the attach succeeded, it receives an "attached" packet; and in the second case, it receives an "exit" packet.<br>To support this property, the thread ignores certain debugger packets in some states (the "interrupt" packet in the **Paused** and **Exited** states, for example). These cases all handle situations where the ignored packet was preempted by some thread action.
 
 Note that the rules here apply to the client's interactions with each thread actor separately. A client may send an "interrupt" to one thread actor while awaiting a reply to a request sent to a different thread actor.
 
 *TODO: What about user selecting nodes in displayed content? Should those be eventy things the client can receive in the "paused" state? What does that mean for the "request"/"reply" pattern?*
 
 ### Attaching To a Thread
 
 To attach to a thread, the client sends a packet of the form:
--- a/devtools/docs/contributing/react-performance-tips.md
+++ b/devtools/docs/contributing/react-performance-tips.md
@@ -273,17 +273,17 @@ more than `Component` with a default imp
 ### About immutability
 #### What it doesn't mean
 It doesn't mean you need to enforce the immutability using a library like
 [Immutable](https://github.com/facebook/immutable-js).
 
 #### What it means
 It means that once a structure exists, you don't mutate it.
 
-**Everytime some data changes, the object reference must change as well**. This
+**Every time some data changes, the object reference must change as well**. This
 means a new object or a new array needs to be created. This gives the nice
 reverse guarantee: if the object reference has changed, the data has changed.
 
 It's good to go one step further to get a **strict equivalence**: if the data
 doesn't change, the object reference mustn't change. This isn't necessary for
 your app to work, but this is a lot better for performance as this avoids
 spurious rerenders.
 
--- a/devtools/docs/frontend/telemetry.md
+++ b/devtools/docs/frontend/telemetry.md
@@ -211,19 +211,19 @@ Notes:
   about toolClosed. Of course, if there was an accompanying `timerHistogram`
   field defined in `telemetry.js` and `histograms.json` then `toolClosed` should
   also be added.
 
 ### 4. Using Events.yaml probes in DevTools code
 
 Once the probe has been declared in the `Events.yaml` file, you'll need to actually use it in our code.
 
-It is crucial to understand that event telemetry have a string identifier which is constructed from the `category`, `method`, `object` (name) and `value` on which the event occured. This key points to an "extra" object that contains further information about the event (we will give examples later in this section).
+It is crucial to understand that event telemetry have a string identifier which is constructed from the `category`, `method`, `object` (name) and `value` on which the event occurred. This key points to an "extra" object that contains further information about the event (we will give examples later in this section).
 
-Because these "extra" objects can be from completely independant code paths we
+Because these "extra" objects can be from completely independent code paths we
 can send events and leave them in a pending state until all of the expected extra properties have been received.
 
 First, include the telemetry module in each tool that requires telemetry:
 
 ```js
 let Telemetry = require("devtools/client/shared/telemetry");
 ```
 
--- a/devtools/docs/preferences.md
+++ b/devtools/docs/preferences.md
@@ -16,17 +16,17 @@ testing DevTools as Firefox panel, or a 
 DevTools relies on nsIPrefBranch for preferences, which supports different types of
 preferences:
 * `Int`
 * `Boolean`
 * `Char`
 * `String`
 
 Choose the appropriate type depending on the data you need to store. If you need to store
-a JavaSript object or array, the recommended way is to:
+a JavaScript object or array, the recommended way is to:
 * use a `String` type preference
 * use JSON.stringify to save
 * use JSON.parse to read
 
 Note that nsIPrefBranch also supports a `Complex` type, but this type is not supported
 when running in Launchpad.
 
 ## Reading and updating preferences
--- a/js/src/doc/Debugger/Debugger.Script.md
+++ b/js/src/doc/Debugger/Debugger.Script.md
@@ -306,17 +306,17 @@ methods of other kinds of objects.
 <code>getPredecessorOffsets(<i>offset</i>)</code>
 :   **If the instance refers to a `JSScript`**, return an array
     containing the offsets of all bytecodes in the script for which
     <i>offset</i> is an immediate successor via non-exceptional
     control flow paths.
 
 `getOffsetsCoverage()`:
 :   **If the instance refers to a `JSScript`**, return `null` or an array which
-    contains informations about the coverage of all opcodes. The elements of
+    contains information about the coverage of all opcodes. The elements of
     the array are objects, each of which describes a single opcode, and
     contains the following properties:
 
     * lineNumber: the line number of the current opcode.
 
     * columnNumber: the column number of the current opcode.
 
     * offset: the bytecode instruction offset of the current opcode.
--- a/js/src/doc/Debugger/Debugger.Source.md
+++ b/js/src/doc/Debugger/Debugger.Source.md
@@ -146,17 +146,17 @@ from its prototype:
     * Source belongs to a DOM element if it was assigned to one of the
       element's event handler IDL attributes as a string. (Note that one may
       assign both strings and functions to DOM elements' event handler IDL
       attributes. If one assigns a function, that function's script's source
       does <i>not</i> belong to the DOM element; the function's definition
       must appear elsewhere.)
 
     (If the sources attached to a DOM element change, the `Debugger.Source`
-    instances representing superceded code still refer to the DOM element;
+    instances representing superseded code still refer to the DOM element;
     this accessor only reflects origins, not current relationships.)
 
 `elementAttributeName`
 :   If this source belongs to a DOM element because it is an event handler
     content attribute or an event handler IDL attribute, this is the name of
     that attribute, a string. Otherwise, this is `undefined`.
 
 `introductionType`
--- a/toolkit/components/normandy/docs/data-collection.rst
+++ b/toolkit/components/normandy/docs/data-collection.rst
@@ -132,17 +132,17 @@ Unenrollment
          * ``"user-preference-changed"``: The study preference was
            changed on the user branch. This could mean the user
            changed the preference, or that some other mechanism set a
            non-default value for the preference.
          * ``"user-preference-changed-sideload"``: The study
            preference was changed on the user branch while Normandy was
            inactive. This could mean that the value was manually
            changed in a profile while Firefox was not running.
-         * ``"unknown"``: A reason was not specificied. This should be
+         * ``"unknown"``: A reason was not specified. This should be
            considered a bug.
 
 Add-on Studies
 ^^^^^^^^^^^^^^
 Enrollment
    method
       The string ``"enroll"``
    object
--- a/tools/lint/codespell.yml
+++ b/tools/lint/codespell.yml
@@ -1,41 +1,46 @@
 ---
 codespell:
     description: Check code for common misspellings
     include:
         - browser/base/content/docs/
         - browser/branding/
+        - browser/components/newtab/docs/
         - browser/components/newtab/prerendered/locales/en-US/
         - browser/extensions/formautofill/locales/en-US/
         - browser/extensions/webcompat-reporter/locales/en-US/
+        - browser/installer/windows/docs/
         - browser/locales/en-US/
         - build/docs/
         - devtools/client/locales/en-US/
+        - devtools/docs/
         - devtools/shared/locales/en-US/
         - devtools/startup/locales/en-US/
         - dom/locales/en-US/
         - gfx/docs/
         - intl/docs/
         - intl/locales/en-US/
+        - js/src/doc/
         - layout/tools/layout-debug/ui/locale/en-US/
         - mobile/android/base/locales/en-US/
         - mobile/android/branding/
         - mobile/android/docs/
         - mobile/android/locales/en-US/
         - mobile/locales/en-US/
         - netwerk/locales/en-US/
         - python/docs/
         - python/mach/docs/
         - python/mozlint/
         - python/safety/
         - services/sync/locales/en-US/
         - taskcluster/docs/
         - testing/mozbase/docs/
         - toolkit/components/extensions/docs/
+        - toolkit/components/normandy/docs/
         - toolkit/components/telemetry/docs/
         - toolkit/crashreporter/docs/
         - tools/lint/
         - tools/tryselect/
     # List of extensions coming from:
     # tools/lint/{flake8,eslint}.yml
     # tools/mach_commands.py (clang-format)
     # + documentation
@@ -49,12 +54,13 @@ codespell:
         - xhtml
         - cpp
         - c
         - h
         - configure
         - py
         - properties
         - rst
+        - md
     support-files:
         - 'tools/lint/spell/**'
     type: external
     payload: spell:lint
--- a/tools/lint/spell/exclude-list.txt
+++ b/tools/lint/spell/exclude-list.txt
@@ -1,6 +1,8 @@
 cas
 optin
 aparent
 acount
 te
 wasn
+incrementall
+aare