cy.visit blank page

Better world by better software

Gleb bahmutov phd , our planet 🌏 is in danger, act today: what you can do, visit the blank page between cypress tests, stop the web application and clearly separate the end-to-end tests by visiting the blank about page after each test..

When a Cypress test finishes, the web application stays in the browser's window. This could be confusing if the next test does not immediately start with cy.visit . For example, the JavaScript callbacks from the application visited in the first test are still executing, and could "leak" into the second test. Imagine the application scheduling code to execute after a delay:

Imagine the test confirming the number of console logs calls. The application is printing a message on start up and when adding a todo. The first test successfully passes

In the screenshot above notice the second log call. It happens after the test has already finished and thus does not affect our assertion cy.get('@log').should('have.been.calledOnce') .

📺 If you prefer watching the explanation to reading this blog post, I have recorded the video Visit The Blank Page Between The Tests .

Let's add a second test that confirms the console.log is called when adding a new Todo item.

The second test fails - there is an extra console.log call that now is included in the second test.

In my case, if the application uses a delay of 30ms when calling the setTimeout , the application because flaky - sometimes the tests pass and sometimes they fail.

I do not have to tell you, how frustrating flaky tests are.

📚 Read my other blog posts about flaky tests on Cypress blog.

A similar situation when the app does something unexpected due to the previous test can happen for other reasons. For example, a long-running network requests can finish and unexpectedly update the app. At best, the application's behavior can be hard to explain. At worst, you can get the dreaded this element is detached from the DOM error.

Solution: visiting a blank page

A good solution to clearly separate the tests and stop any application callbacks is to visit a "neutral" blank page. Unfortunately, using the cy.visit('about:blank') would not work.

Notice the URL in the browser - we did NOT visit the about:blank page, instead we have visited our baseUrl + about:blank !

We need another way of visiting the blank page. We can use the window.location = 'about:blank' instead. Note: we also need to visit the page in every test.

The passing tests show the expected calls - and nothing else.

The callback from the application is truly canceled. You can confirm it is never executed by looking at the DevTools console. The log message "running app code" is never printed, because the JavaScript VM executing the application code for localhost:3000 is stopped.

Notice the application page is blank - because we visit the blank pages after each test. We could leave the application running and instead visit the blank page before each test. In that case make sure the about:page callback is the very first callback executed for each test. A good idea is to place it into the support file, because that file is always loaded before the spec file loads.

A common mistake when using cy.session() (and how to fix it)

February 8, 2023

This is a guest post from Ambassador Filip Hric! Hello, I’m Filip. I teach testers about web development and developers about testing. I have spoken at conferences around the world, created multiple online courses, and host live workshops on e2e testing in Cypress.io. Find everything I do at https://filiphric.com.

In Cypress v12, the cy.session() command was released as generally available. Many teams have already added it to their projects to save minutes from their test runs.

I recently wrote a blogpost on how cy.session() can be used instead of abstracting login logic into a page object. As community members on my Discord implement cy.session() into their projects, I often see one problem pop up repeatedly. Let me give you an example.

Consider this login flow:

By applying the cy.session() API, we can cache the cookies, localStorage and sessionStorage state of our browser for this login flow like this:

There is one small problem with this type of login. As soon as Cypress completes the cy.type() function, it caches our browser state. However, our frontend might still be working on the login flow and some of the authentication data we need has not been set.

Let’s say our application login will send an http request to the server to authenticate the user, and then redirect to a home page, before saving cookies into the browser.

Given the example above, our session will not get properly cached because we didn’t not explicitly tell cy.session() authentication flow is still in progress. The easiest way we can fix that is to add a guarding assertion to our session.

This way we will ensure that Cypress will cache our browser at the right moment. Depending on our application, this might be right after we navigate to a new page or some time later. The exact point will be determined by the application we are testing.

Usually, when making a login action, a server responds with an authorization in the form of a token that gets saved as cookies or some other browser storage. Instead of checking for the location, we can check that storage item. The session might then look something like this:

There is a slight problem with this approach though. The cy.getCookie() command will execute immediately and will not retry. Instead of using cy.getCookie() command we will choose a slightly different approach.

This way we can ensure that we wait the proper time for the application to store our cookies in the browser. After our cookies are saved, we can safely cache our session and use it in our tests.

The validation of a successful login is important for the cy.session() command to work properly. In fact, when using cy.session() you can add the validation as a separate step. This is what the validate() function is for. Let’s see it in action:

In this simple example, cy.session() will work pretty much the same way as before. But there is one upside to this approach. Our validate() function can do more than check the mere presence of the token. Instead, we could check for the validity of the token and make sure it does not expire during, e.g., a longer test run. The validate function can look something like this:

If the cy.request() returns an error code, it will mean that our authorization is no longer valid and we need to log in again. The validate() function will take care of this, and re-run our login flow.

This way we still keep login attempts to minimum, while making sure that the authorization does not expire during the test run.

Remember to always ensure that your cy.session() flow contains a “confirming assertion” that will guard the creation of the session to proper time.

About the Ambassador Program

The Cypress Ambassador program supports the top Cypress advocates around the world. Through this program, Ambassadors are offered speaking opportunities, a personalized hub, and visibility within our extensive network.To learn more about these wonderful ambassadors visit our Official Ambassador webpage.

Your One-Stop Guide to cy.visit() in Cypress: Usage, Examples, and Best Practices

Cypress and visit Command Overview:

Cypress: A JavaScript-based end-to-end (E2E) testing framework for modern web applications. It facilitates creating and running automated tests that interact with the browser UI, ensuring the application behaves as expected.

cy.visit() Command: This crucial Cypress command serves as the entry point for your tests. It navigates the browser to a specified URL, loading the corresponding web page. This action lays the groundwork for subsequent interactions with the page's elements.

Optional Parameters:

• timeout (Number): Sets the maximum wait time (in milliseconds) for the page to load. The default is 30000 (30 seconds).
• onBeforeLoad (Function): Executes a callback function before the page finishes loading. Useful for setting up test data or environment configurations.
• onLoad (Function): Executes a callback function after the page finishes loading. Typically used for assertions or initial interactions.

Example Code:

• Reloading Window: Visiting a new domain or subdomain necessitates the Cypress window to reload. To test across different domains, use the cy.origin() command.
• Automatic baseUrl Prefixing: If you've set a baseUrl configuration in Cypress, cy.visit() will automatically prepend it to the provided URL.

Potential Errors:

• Timeout Error: If the page loading exceeds the specified timeout, Cypress throws a timeout error.
• Network Errors: Connectivity or server issues can lead to network errors, preventing successful page loading.
• JavaScript Errors: Issues within the website's JavaScript code might interfere with the Cypress test execution.

Error Handling:

• Use cy.on('uncaught:exception', (err) => { ... }) to handle expected or unexpected JavaScript errors.
• Implement retries with cy.reload() or cy.wait() in case of temporary network failures.

Best Practices:

• Employ descriptive URLs for clarity and maintainability.
• Set appropriate timeouts based on page loading expectations.
• Handle errors gracefully to prevent test failures due to external factors.

By effectively incorporating the cy.visit() command and considering the provided best practices, you can streamline your Cypress test writing experience and ensure your web applications function correctly across different scenarios.

Visit a remote URL.

Best Practice We recommend setting a baseUrl when using cy.visit() . Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your global configuration if set.

If the baseUrl has not been set, you will need to specify a fully qualified URL or Cypress will attempt to act as your web server. See the prefixes notes for more details.

Note: visiting a new domain requires the Test Runner window to reload. You cannot visit different super domains in a single test.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

By default, the cy.visit() commands' will use the pageLoadTimeout and baseUrl set globally in your configuration .

You can also set all cy.visit() commands' pageLoadTimeout and baseUrl globally in configuration .

• cy.visit() 'yields the window object after the page finishes loading'

Let's confirm the window.navigator.language after visiting the site:

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Overrides the pageLoadTimeout set globally in your configuration for this page load.

Add basic auth headers

Cypress will automatically apply the right authorization headers if you're attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you're testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it's a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() 's onBeforeLoad option to: Bootstrapping your App Set a token to localStorage for login during Single Sign On Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query parameters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit is automatically prefixed with baseUrl

Cypress will prefix the URL with the baseUrl if it has been set. We recommending configuring the baseUrl in the your configuration file ( cypress.json by default) to prevent repeating yourself in every cy.visit() command.

If you would like to visit a different host when the baseUrl has been set, provide the fully qualified URL you would like to go to.

Visit local files

Cypress will automatically attempt to serve your files if you don't provide a host and the baseUrl is not defined . The path should be relative to your project's root folder (where the cypress.json file is generated by default).

Having Cypress serve your files is useful in smaller projects and example apps, but isn't recommended for production apps. It is always better to run your own server and provide the URL to Cypress.

Visit local file when baseUrl is set

If you have baseUrl set, but need to visit a local file in a single test or a group of tests, set the baseUrl to null by using a test configuration . Given our cypress.json file:

The first test visits the baseUrl , while the second test visits the local file.

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you're not using one of these 3 hosts, then make sure to provide the protocol.

Visit will always yield the remote page's window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.intercept() command is not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.intercept() route will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

• cy.visit() requires being chained off of cy .
• cy.visit() requires the response to be content-type: text/html .
• cy.visit() requires the response code to be 2xx after following redirects.
• cy.visit() requires the load load event to eventually fire.
• cy.visit() will automatically wait for assertions you have chained to pass
• cy.visit() can time out waiting for the page to fire its load event.
• cy.visit() can time out waiting for assertions you've added to pass.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

© 2017 Cypress.io Licensed under the MIT License. https://docs.cypress.io/api/commands/visit

Unleash the Power of Cypress: Configuration API for Streamlined Testing

Cypress Configuration APICypress offers a robust Configuration API that empowers you to tailor test execution to your specific project requirements

• Boosting Your Testing Workflow: An Exploration of Cypress and Cypress.log
• Cypress scrollIntoView : Your Toolkit for Effective Element Scrolling
• Mastering Cypress: Using .blur() for Effective End-to-End Testing

Cypress cy.reload() : Unleash the Power of Refreshing Your Tests

Visual Debugging Made Easy: Unveiling Your App's Secrets with Cypress

Unveiling the power of the cypress server for web application testing.

Visit a remote URL.

Best Practice

We recommend setting a baseUrl when using cy.visit() .

Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your global configuration if set.

If the baseUrl has not been set, you will need to specify a fully qualified URL or Cypress will attempt to act as your web server. See the prefixes notes for more details.

Note: visiting a new domain requires the Cypress window to reload. You cannot visit different super domains in a single test.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

By default, the cy.visit() commands' will use the pageLoadTimeout and baseUrl set globally in your configuration .

You can also set all cy.visit() commands' pageLoadTimeout and baseUrl globally in the Cypress configuration .

• cy.visit() yields the window object after the page finishes loading.
• It is unsafe to chain further commands that rely on the yielded window after cy.visit() .

Let's confirm the window.navigator.language after visiting the site:

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Overrides the pageLoadTimeout set globally in your configuration for this page load.

Add basic auth headers

Cypress will automatically apply the right authorization headers if you're attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you're testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it's a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() 's onBeforeLoad option to:

• Bootstrapping your App
• Set a token to localStorage for login during Single Sign On
• Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query parameters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit is automatically prefixed with baseUrl

Cypress will prefix the URL with the baseUrl if it has been set. Configure baseUrl in the Cypress configuration to prevent repeating yourself in every cy.visit() command.

The cypress.json file has been replaced by cypress.config.js or cypress.config.ts in Cypress version 10.0.0. We recommend that you update your configuration accordingly.

Please see the new configuration guide and the migration guide for more information.

If you would like to visit a different host when the baseUrl has been set, provide the fully qualified URL you would like to go to.

Visit local files

Cypress will automatically attempt to serve your files if you don't provide a host and baseUrl is not defined . The path should be relative to your project's root folder (the directory that contains the Cypress configuration file ).

Having Cypress serve your files is useful in smaller projects and example apps, but isn't recommended for production apps. It is always better to run your own server and provide the url to Cypress.

Visit local file when baseUrl is set

If you have baseUrl set, but need to visit a local file in a single test or a group of tests, disable the baseUrl using per-test configuration . Imagine this Cypress configuration:

The first test visits the baseUrl , while the second test visits the local file.

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you're not using one of these 3 hosts, then make sure to provide the protocol.

Visit will always yield the remote page's window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.intercept() command is not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.intercept() route will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

• cy.visit() requires being chained off of cy .
• cy.visit() requires the response to be content-type: text/html .
• cy.visit() requires the response code to be 2xx after following redirects.
• cy.visit() requires the load load event to eventually fire.
• cy.visit() will automatically wait for assertions you have chained to pass
• cy.visit() can time out waiting for the page to fire its load event.
• cy.visit() can time out waiting for assertions you've added to pass.

Visiting cross-origin sites

After visiting a cross-origin site, to interact with the content, you must use a cy.origin() block.

When visiting a cross-origin site, the onBeforeLoad and onLoad options are not supported.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

Visit a remote URL.

Best Practice We recommend setting a baseUrl when using cy.visit() . Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your network options if you’ve set one.

You may also specify the relative path of an html file. The path is relative to the root directory of the Cypress installation. Note that the file:// prefix is not needed.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

You can also set all cy.visit() commands’ pageLoadTimeout and baseUrl globally in configuration .

cy.visit() yields the window object after the page finishes loading.

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Add basic auth headers.

Cypress will automatically apply the right authorization headers if you’re attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you’re testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it’s a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() ‘s onBeforeLoad option to: Bootstraping your App Set a token to localStorage for login during Single Sign On Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query paramaters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you’re not using one of these 3 hosts, then make sure to provide the protocol.

Cypress can optionally act as your web server

Cypress will automatically attempt to serve your files if you don’t provide a host and baseUrl is not defined . The path should be relative to your project’s root folder (where the cypress.json file is generated by default).

Having Cypress serve your files is useful in smaller projects and example apps, but isn’t recommended for production apps. It is always better to run your own server and provide the url to Cypress.

Visit is automatically prefixed with baseUrl

Configure baseUrl in the your configuration file ( cypress.json by default) to prevent repeating yourself in every cy.visit() command.

Visit will always yield the remote page’s window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent XHR / Ajax requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.server() and cy.route() commands are not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.server() will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the server and routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

cy.visit() requires being chained off of cy .

cy.visit() requires the response to be content-type: text/html .

cy.visit() requires the response code to be 2xx after following redirects.

cy.visit() requires the load load event to eventually fire.

cy.visit() will automatically wait for assertions you've chained to pass.

cy.visit() can time out waiting for the page to fire its load event.

cy.visit() can time out waiting for assertions you've added to pass.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

© 2020 Cypress.io Licensed under the MIT License. https://docs.cypress.io/api/commands/visit.html

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cy.visit('/') loads blank page. #8904

kavitha24 commented Oct 21, 2020 • edited by jennifer-shehane

jennifer-shehane commented Dec 9, 2020

Sorry, something went wrong.

No branches or pull requests

Visit multiple domains of different origin in a single test.

In normal use, a single Cypress test may only run commands in a single origin, a limitation determined by standard web security features of the browser. The cy.origin() command allows your tests to bypass this limitation.

Obstructive Third Party Code

By default Cypress will search through the response streams coming from your server on first party .html and .js files and replace code that matches patterns commonly found in framebusting. When using the cy.origin() command, the third party code may also need to be modified for framebusting techniques. This can be enabled by setting the experimentalModifyObstructiveThirdPartyCode flag to true in the Cypress configuration. More information about this experimental flag can be found on our Web Security page.

Correct Usage

Incorrect Usage

Arguments ​

url (String)

A URL specifying the secondary origin in which the callback is to be executed. This should at the very least contain a hostname, and may also include the protocol, port number & path. The hostname must precisely match that of the secondary origin, including all subdomains. Query params are not supported.

This argument will be used in two ways:

It uniquely identifies a secondary origin in which the commands in the callback will be executed. Cypress will inject itself into this origin, and then send it code to evaluate in that origin, without violating the browser's same-origin policy.

It overrides the baseUrl configured in your global configuration while inside the callback. So cy.visit() and cy.request() will use this URL as a prefix, not the configured baseUrl .

options (Object)

Pass in an options object to control the behavior of cy.origin() .

The args object is the only mechanism via which data may be injected into the callback, the callback is not a closure and does not retain access to the JavaScript context in which it was declared. Values passed into args must be serializable.

callbackFn (Function)

The function containing the commands to be executed in the secondary origin.

This function will be stringified, sent to the Cypress instance in the secondary origin and evaluated. If the args option is specified, the deserialized args object will be passed into the function as its first and only argument.

There are a number of limitations placed on commands run inside the callback, please see Callback restrictions section below for a full list.

• cy.origin() yields the value yielded by the last Cypress command in the callback function.
• If the callback contains no Cypress commands, cy.origin() yields the return value of the function.
• In either of the two cases above, if the value is not serializable, attempting to access the yielded value will throw an error.

Using dynamic data in a secondary origin ​

Callbacks are executed inside an entirely separate instance of Cypress, so arguments must be transmitted to the other instance by means of the structured clone algorithm . The interface for this mechanism is the args option.

Yielding a value ​

Values returned or yielded from the callback function must be serializable or they will not be returned to the primary origin. For example, the following will not work:

Instead, you must explicitly yield a serializable value:

Navigating to secondary origin with cy.visit ​

When navigating to a secondary origin using cy.visit() , you can either navigate prior to or after the cy.origin block. Errors are no longer thrown on cross-origin navigation, but instead when commands interact with a cross-origin page.

Here the baseUrl inside the cy.origin() callback is set to example.cypress.io and the protocol defaults to https . When cy.visit() is called with the path /history/founder , the three are concatenated to make https://example.cypress.io/history/founder .

Alternative navigation ​

Here the cross-origin page is visited prior to the cy.origin block, but any interactions with the window are performed within the block which can communicate with the cross-origin page

Incorrect Usage ​

Here cy.get('h1') fails because we are trying to interact with a cross-origin page outside of the cy.origin block, due to 'same-origin' restrictions, the 'localhost' javascript context can't communicate with 'cypress.io'.

Navigating to secondary origin with UI ​

Navigating to a secondary origin by clicking a link or button in the primary origin is supported.

Navigating to multiple secondary origins in succession ​

Callbacks may not themselves contain cy.origin() calls, so when visiting multiple origins, do so at the top level of the test.

SSO login custom command ​

A very common requirement is logging in to a site before running a test. If login itself is not the specific focus of the test, it's good to encapsulate this functionality in a login custom command so you don't have to duplicate this login code in every test. Here's an idealized example of how to do this with cy.origin() .

Inefficient Usage

Having to go through an entire login flow before every test is not very performant. Up until now you could get around this problem by putting login code in the first test of your file, then performing subsequent tests reusing the same session.

However, this is no longer possible, since all session state is now cleared between tests. So to avoid this overhead we recommend you leverage the cy.session() command, which allows you to easily cache session information and reuse it across tests. So now let's enhance our custom login command with cy.session() for a complete syndicated login flow with session caching and validation. No mocking, no workarounds, no third-party plugins!

Learn More ​

How to test multiple origins ​.

In this video we walk through how to test multiple origins in a single test. We also look at how to use the cy.session() command to cache session information and reuse it across tests.

Serialization ​

When entering a cy.origin() block, Cypress injects itself at runtime, with all your configuration settings, into the requested origin, and sets up bidirectional communication with that instance. This coordination model requires that any data sent from one instance to another be serialized for transmission. It is very important to understand that variables inside the callback are not shared with the scope outside the callback. For example this will not work:

Instead, the variable must be explicitly passed into the callback using the args option:

Cypress uses the structured clone algorithm to transfer the args option to the secondary origin. This introduces a number of restrictions on the data which may be passed into the callback.

Dependencies / Sharing Code ​

Within the cy.origin() callback, Cypress.require() can be utilized to include npm packages and other files. It is functionally the same as using CommonJS require() in browser-targeted code.

Note that it is not possible to use CommonJS require() or ES module import() within the callback.

Using Cypress.require() within the callback requires enabling the experimentalOriginDependencies option in the Cypress configuration.

Read more in the Cypress.require() doc itself.

Custom commands ​

This makes it possible to share custom commands between tests run in primary and secondary origins. We recommend this pattern for setting up your support file and setting up custom commands to run within the cy.origin() callback:

cypress/support/commands.js :

cypress/support/e2e.js :

cypress/e2e/spec.cy.js :

Shared execution context ​

The JavaScript execution context is persisted between cy.origin() callbacks that share the same origin. This can be utilized to share code between successive cy.origin() calls.

Callback restrictions ​

Because of the way in which the callback is transmitted and executed, there are certain limitations on what code may be run inside it. In particular, the following Cypress commands will throw errors if used in the callback:

• cy.origin()
• cy.intercept()
• cy.session()

Other limitations ​

There are other testing scenarios which are not currently covered by cy.origin() :

• It cannot run commands in a different browser window
• It cannot run commands in a different browser tab
• It cannot run commands inside an <iframe> element

However, <iframe> support is on our roadmap for inclusion in a future version of Cypress.

• Easily test multi-domain workflows with cy.origin
• Custom Commands
• Cypress.require()
• Using dynamic data in a secondary origin
• Yielding a value
• Navigating to secondary origin with cy.visit
• Navigating to secondary origin with UI
• Navigating to multiple secondary origins in succession
• SSO login custom command
• How to Test Multiple Origins
• Serialization
• Dependencies / Sharing Code
• Callback restrictions
• Other limitations