We break down our scripts (Real Browser and Scripted Optimization scans) as having three primary actions:
- Navigating to a page
- Looking for elements
- Performing an action on those elements
Each of these actions has its own set of timeouts that it uses to determine when something fails or when it is time to move onto the next step.
When debugging issues with Real Browser Checks, it is important to understand which of these three actions is causing trouble so you can better understand fix it.
A thorough description of these actions and associated timeouts is detailed below:
Navigating to a page
These are steps where we either request a page explicitly ("Go to URL" steps) or implicitly (we clicked a link on a page which triggered a navigation).
There are two scenarios that can cause us to get no data back for the navigation event and ultimately fail the check:
- We were unable to establish a connection to the server - In this scenario we tried to connect to the server for up to 118 seconds but were unable to do so. Because of this, all we can really tell the user is that we tried. This results in a message similar to:
http://blackhole.webpagetest.org/ failed to load in 118 seconds
As an example locally, you can go to http://blackhole.webpagetest.org and see that it hangs forever until your browser finally tells you that it cannot connect.
2. We were able to establish a connection but it failed due to a number of different issues (bad SSL certificate, infinite redirects, etc). In these cases, we take the error message from the browser and relay that to the user in the failure message:
Insecure Connection (SEC_ERROR_UNKNOWN_ISSUER): https://self-signed.badssl.com/
If we hit either of those two scenarios, we fail the check and return immediately and do not attempt to run any additional steps.
If we are able to connect to the website and start to get content, then there are a number of different timeouts that are used.
The most we will ever wait for a page to fully-load is 118 seconds.
We start loading all of the resources on the page and wait for the browser to fire the onload event. IF this event fires, then we wait for one of the following to occur:
- The network becomes inactive at which point we consider the page to be fully-loaded
- Five seconds have passed since onload and the network has not become inactive. At this point we terminate all active connections and consider the page to be fully-loaded
If onload never fires (this happens sometimes with media sites), then we wait for the 118 second limit and check to see that there were assets in the HAR. As long as there are requests, we consider the check to have succeeded, it just will not have a value for onload in the app.
Looking for Elements
Our action steps are shown in the Steps dropdown and are where we're (typically) operating on some element on the page (clicking a button, filling out a field), etc.
Before we can interact with the element, we must find the element first.
For action steps, we look for the element for up to 5 seconds.
As soon as we find the element, we perform the action. If we do not find the element after 5 seconds, we return an error and fail that particular step:
Element not found with id=inputStartURLList
Wait steps are shown in the Steps UI at the bottom (e.g. Wait for Element Visible). For these steps there is no action, but we're waiting for an element to be either present or absent from the DOM and have specific properties.
For explicit wait steps we wait for a maximum of 10 seconds for the conditions to be true
If we find the element matching the step, we return successfully, otherwise we fail the step and return an error:
Timed out while waiting for element id=inputEmailBOGUS
Performing an action on those elements
For our action steps (clicking buttons, filling out a field), they can potentially trigger a navigation event. For example, if you click on a "Login" button after filling out your username and password, it will take you to a new page. If you click on a link, it will take you to a new page. When this happens, we treat this new page as if it was our normal navigation step. This means that we wait for the navigation to complete on this new page before we consider the step to be complete.
- For navigation events, we wait for up to 118 seconds for the page to fully load (onload fires and we have network inactivity or onload never happened but we waited for 118 seconds and saw network activity)
- For action steps, we look for the element for up to 5 seconds and then after performing the action wait for 2 seconds to see if a navigation event was triggered in which case the navigation event rules kick in
- For wait steps, we look for the element or text for up to 10 seconds