more minor changes to pages

Author: jennifer-shehane

source/api/commands/screenshot.md

@@ -1,6 +1,5 @@
 ---
 title: screenshot
-
 ---
 
 Take a screenshot of the application under test and, optionally, the {% url "Cypress Command Log" test-runner#Command-Log %}.
@@ -42,15 +41,15 @@ Pass in an options object to change the default behavior of `.screenshot()`.
 
 Option |Default | Description
 --- | --- | ---
-`log` | `true` | {% usage_options log %}
 `blackout` | `[]` | Array of string selectors used to match elements that should be blacked out when the screenshot is taken. Does not apply to `runner` captures.
 `capture` | `'fullPage'` | Which parts of the Test Runner to capture. This value is ignored for element screenshot captures. Valid values are `viewport`, `fullPage`, or `runner`. When `viewport`, the application under test is captured in the current viewport. When `fullPage`, the application under test is captured in its entirety from top to bottom. When `runner`, the entire browser viewport, including the Cypress Command Log, is captured.  For screenshots automatically taken on test failure, capture is always coerced to `runner`.
 `clip` | `null` | Position and dimensions (in pixels) used to crop the final screenshot image. Should have the following shape: `{ x: 0, y: 0, width: 100, height: 100 }`
 `disableTimersAndAnimations` | `true`| When true, prevents JavaScript timers (`setTimeout`, `setInterval`, etc) and CSS animations from running while the screenshot is taken.
-`scale` | `false` | Whether to scale the app to fit into the browser viewport. This is always coerced to `true` when `capture` is `runner`.
-`timeout` | {% url `responseTimeout` configuration#Timeouts %} | {% usage_options timeout .screenshot %}
+`log` | `true` | {% usage_options log %}
 `onBeforeScreenshot` | `null` | A callback before a (non-failure) screenshot is taken. For an element capture, the argument is the element being captured. For other screenshots, the argument is the `$el`.
 `onAfterScreenshot` | `null` | A callback after a (non-failure) screenshot is taken. For an element capture, the first argument is the element being captured. For other screenshots, the first argument is the `$el`. The second argument is properties concerning the screenshot, including the path it was saved to and the dimensions of the saved screenshot.
+`scale` | `false` | Whether to scale the app to fit into the browser viewport. This is always coerced to `true` when `capture` is `runner`.
+`timeout` | {% url `responseTimeout` configuration#Timeouts %} | {% usage_options timeout .screenshot %}
 
 For more details on these options and to set some as defaults across all uses of `.screenshot()`, see the {% url 'Cypress.Screenshot API doc' screenshot-api %}.
 

source/api/events/configuration-event.md

@@ -41,7 +41,7 @@ Whenever you return an object from your `backgroundFile`, Cypress will take this
 
 If you don't return an object, then configuration will not be modified.
 
-Resolved values will show up in your Settings tab.
+Resolved values will show up in your Settings tab in the Test Runner.
 
 {% img /img/guides/background-configuration.png %}
 
@@ -69,7 +69,7 @@ module.exports = (on, config) => {
 }
 ```
 
-You could now swap out configuration + environment variables like so:
+You could now swap out configuration and environment variables like so:
 
 ```shell
 cypress run

source/api/events/file-preprocessor-event.md

@@ -2,7 +2,7 @@
 title: file:preprocessor Event
 ---
 
-The `file:preprocessor` event allows you to modify how your spec files and support file are preprocessed for the browser.
+The `file:preprocessor` event allows you to modify how your spec files and support files are preprocessed for the browser.
 
 A preprocessor is the plugin responsible for preparing a {% url "support file" writing-and-organizing-tests#Support-file %} or a {% url "test file" writing-and-organizing-tests#Test-files %} for the browser.
 
@@ -16,7 +16,7 @@ Occurs only in the {% url "background process" background-process %}.
 
 # Examples
 
-We've created three preprocessors as examples for you to look at. These are fully functioning preprocessors.
+We've have three preprocessors as examples. These are fully functioning preprocessors.
 
 The code contains comments that explain how it utilizes the preprocessor API.
 
@@ -26,7 +26,7 @@ The code contains comments that explain how it utilizes the preprocessor API.
 
 # Recipes
 
-We've also added some recipes showing how to utilize these preprocessors.
+We've also have some recipes showing how to utilize these preprocessors.
 
 Here are two recipes using both webpack and browserify to write your tests in TypeScript.
 
@@ -46,9 +46,7 @@ The Browserify Preprocessor handles:
 
 The exact default configuration options {% url 'can be found here' https://github.com/cypress-io/cypress-browserify-preprocessor#browserifyoptions %}.
 
-{% note info %}
-Are you looking to change the **default options** for Browserify?
-{% endnote %}
+{% note info "Are you looking to change the default options for Browserify?" %}
 
 Changing the Browserify options lets you:
 
@@ -57,10 +55,11 @@ Changing the Browserify options lets you:
 - Add support for CoffeeScript `2.x.x`
 
 Please read this link in the {% url 'browserify preprocessor' https://github.com/cypress-io/cypress-browserify-preprocessor#modifying-default-options %} repo for instructions on modifying these.
+{% endnote %}
 
 # Usage
 
-To use a preprocessor, you should bind to the `file:preprocessor` event in your {% url "`backgroundFile`" configuration#Folders-Files %}:
+To use a preprocessor, you should bind to the `file:preprocessor` event in your {% url "`backgroundFile`" configuration#Folders-Files %}.
 
 ```javascript
 // background file
@@ -82,7 +81,8 @@ module.exports = (on, config) => {
 
 > \*\* The built file is the file that is created by the preprocessor that will eventually be served to the browser.
 
-> If, for example, the source file is `spec.coffee`, the preprocessor should:
+If, for example, the source file is `spec.coffee`, the preprocessor should:
+
 1. Compile the CoffeeScript into JavaScript `spec.js`
 2. Write that JavaScript file to disk (example: `/Users/foo/tmp/spec.js`)
 3. Resolve with the absolute path to that file: `/Users/foo/tmp/spec.js`
@@ -114,7 +114,6 @@ The `file` object passed to the callback function is an {% url "Event Emitter" h
 When the running spec, the project, or the browser is closed while running tests, the `close` event will be emitted. The preprocessor should do any necessary cleanup in this function, like closing the watcher when watching.
 
 ```javascript
-// example
 const watcher = fs.watch(filePath, /* ... */)
 
 file.on('close', () => {
@@ -127,7 +126,6 @@ file.on('close', () => {
 If watching for file changes, emit `rerun` after a file has finished being processed to let Cypress know to rerun the tests.
 
 ```javascript
-// example
 fs.watch(filePath, () => {
   file.emit('rerun')
 })
@@ -147,4 +145,4 @@ Use the following npm keywords:
 ]
 ```
 
-Feel free to submit your published plugins to our {% url "list of plugins" plugins %}.
+Feel free to submit your published plugin to our {% url "list of plugins" plugins %}.

source/guides/core-concepts/writing-and-organizing-tests.md

@@ -93,7 +93,7 @@ To start writing tests for your app, simply create a new file like `app_spec.js`
 
 ## Background file
 
-Cypress runs a background Node.js process that you can utilize via the the background file (`cypress/background/index.js` by default).
+Cypress runs a background Node.js process that you can utilize via the the {% url "background file" configuration#Folders-Files %} (`cypress/background/index.js` by default).
 
 {% url "Read more about using the background process to extend Cypress behavior." background-process %}
 

source/guides/references/configuration.md

@@ -50,7 +50,7 @@ Option | Default | Description
 `fileServerFolder`    | root project folder    |Path to folder where application files will attempt to be served from
 `fixturesFolder`    | `cypress/fixtures`    | Path to folder containing fixture files (Pass `false` to disable)
 `integrationFolder` | `cypress/integration` | Path to folder containing integration test files
-`backgroundFile` | `cypress/background/index.js` | Path to background file. (Pass `false` to disable)
+`backgroundFile` | `cypress/background/index.js` | Path to {% url "background file" background-process %}. (Pass `false` to disable)
 `screenshotsFolder`     | `cypress/screenshots`     | Path to folder where screenshots will be saved from {% url `cy.screenshot()` screenshot %} command or after a test fails during `cypress run`
 `supportFile` | `cypress/support/index.js` | Path to file to load before test files load. This file is compiled and bundled. (Pass `false` to disable)
 `videosFolder`     | `cypress/videos`     | Path to folder where videos will be saved during `cypress run`
@@ -123,9 +123,9 @@ cypress run --record --config viewportWidth=1280,viewportHeight=720
 
 ## Background Process
 
-As of {% url `1.2.0` changelog#1-2-0 %} you can programmatically modify configuration values using Node.js code via the {% url "background process" background-process %}. This enables you to do things like use `fs` and read off configuration values and dynamically change them.
+As of {% url `1.2.0` changelog#1-2-0 %} you can programmatically modify configuration values using Node.js code via the {% url "background process" background-process %}. This enables you to do things like use `fs` or read and dynamically change configuration values.
 
-While this may take a bit more work than other options - it yields you the most amount of flexibility and the ability to manage configuration however you'd like.
+While this may take a bit more work than other options - it yields you the most amount of flexibility to manage configuration however you'd like.
 
 {% url "We've fully documented how to do this here." configuration-event %}
 

source/guides/references/error-messages.md

@@ -526,4 +526,4 @@ This error likely appeared because:
 
 WIP. We'll be adding more here soon.
 
-For now, please view the {% url 'details on the `uncaught-exception` event' uncaught-exception-event %} for examples how to turn off catching uncaught exceptions.
+For now, please view the {% url 'details on the `uncaught-exception` event' uncaught-exception-event %} for examples on how to turn off catching uncaught exceptions.

source/guides/references/migration-guide.md

@@ -6,15 +6,15 @@ title: Migration Guide
 
 ## pluginsFile renamed to backgroundFile
 
-The `pluginsFile` configuration property has been renamed to `backgroundFile`. 
+The `pluginsFile` configuration property has been renamed to {% url "`backgroundFile`" configuration#Folders-Files %}. In your `cypress.json` file...
 
 ```json
 {
   "pluginsFile": "path/to/file.js"
 }
 ```
 
-should become:
+...should be changed to:
 
 ```json
 {
@@ -24,7 +24,7 @@ should become:
 
 ## Default background file path changed
 
-The default path of the {% url 'background file' background-process %} (previously known as the plugins file) has been changed from `cypress/plugins/index.js` to `cypress/background/index.js`. If you don't explicitly set the `backgroundFile` to a custom path, you'll need to move your background file to the new default path.
+The default path of the {% url 'background file' background-process %} (previously known as the plugins file) has been changed from `cypress/plugins/index.js` to `cypress/background/index.js`. If you don't explicitly set the `backgroundFile` to a custom path, you'll need to move your background file to the new default path. In your `cypress` folder...
 
 ```text
 /cypress
@@ -35,7 +35,7 @@ The default path of the {% url 'background file' background-process %} (previous
     - index.js
 ```
 
-should become:
+...should be changed to:
 
 ```text
 /cypress
@@ -48,12 +48,14 @@ should become:
 
 ## Events renamed
 
-Various events have been renamed to a more consistent format. If you listen for any of the following events in your test code, you'll need to rename them.
+Various events have been renamed to maintain a more consistent format. If you listen for any of the following events in your test code, you'll need to rename them.
 
-- `test:before:run` renamed to `before:test:run`
-- `test:after:run` renamed to `after:test:run`
-- `window:before:load` renamed to `before:window:load`
-- `window:before:unload` renamed to `before:window:unload`
+- Rename `test:before:run` to `before:test:run`
+- Rename `test:after:run` to `after:test:run`
+- Rename `window:before:load` to `before:window:load`
+- Rename `window:before:unload` to `before:window:unload`
+
+In your test code...
 
 ```javascript
 Cypress.on('test:before:run', () => {
@@ -65,7 +67,7 @@ cy.on('window:before:load', () => {
 })
 ```
 
-should become:
+...should become:
 
 ```javascript
 Cypress.on('before:test:run', () => {

source/guides/references/trade-offs.md

@@ -53,7 +53,7 @@ In case you missed it before - Cypress tests run inside of the browser! This mea
 
 But what this also means is that your test code **is being evaluated inside the browser**. Test code is not evaluated in Node.js, or any other server side language. The **only** language we will ever support is the language of the web: JavaScript.
 
-This trade-off means it makes it a little bit harder to communicate with the backend - like your server or database. You will not be able to connect or import those server-side libraries or modules directly. Although you can of course require `node_modules` which can be used in the browser. Additionally, you have the ability to use Node.js to import or talk directly to your backend scripts using {% url "`cy.task()`" task %} in {% url "the background process" background-process %}.
+This trade-off means it makes it a little bit harder to communicate with the backend - like your server or database. You will not be able to connect or import those server-side libraries or modules directly. Although you can require `node_modules` which can be used in the browser. Additionally, you have the ability to use Node.js to import or talk directly to your backend scripts using {% url "`cy.task()`" task %} in the {% url "background process" background-process %}.
 
 To talk to your database or server you need to use the {% url `cy.exec()` exec %}, {% url `cy.task()` task %}, or {% url `cy.request()` request %} commands. That means you will need to expose a way to seed and setup your database. This really is not that hard, but it might take a bit more elbow grease than other testing tools written in your backend language.