JavaScript interaction
The ScreenshotDriver requires calls to JavaScript on a web page to perform certain tasks such as ensuring the page is loaded, determining the height of the viewport, determining the height of the full web page, and scrolling down the page in the browser. The system attempts to handle various cases where these calls to JavaScript return invalid results, but will give up when unrecoverable errors are encountered.
Screenshot fails to generate Full Page correctly
To generate a Full Page screenshot, CrossBrowserTesting software will scroll your webpage and capture images to then stitch them together as one final image.
There are a few reasons the screenshot system will fail to create a full page and instead will only show the first viewport, but the most common one is that the natural CSS overflow of content scrolling has been moved off of the <body> tag and instead exists on a child element. You can test the two JavaScript commands to verify this is the case:
// This JavaScript call is the default choice for how
// CrossBrowserTesting will "scroll" the page and generate a fullpage screenshot
window.document.body.style.transform='translate(100vh)'; //should move the page down one viewport-height
// This method is used when you select "Use Standard Scroll" in Advanced Options
window.scrollTo(0,500); //should move the page down 500 pixels
When neither of these commands scroll the page down, most likely the scrolling element has been changed as described. We cannot support full page screenshots for webpages that move the scroll to a child element.
Page load timeouts
A web page has about 30 seconds to load such that the browser returns a signal that the page is ready. In some cases, after the 30 second timeout, additional steps are made to verify or not if the page is in fact ready but just has not communicated this back. Within 30 – 60 seconds of requesting the page, if the ScreenshotDriver is unable to begin interacting with the page, the system will give up and mark the test as failed. This issue can be related to operating system, browser, or network issues, as well as slow response time by the website requested or lots of elements on the page itself. Ensure your page is able to load in a timely manner to help avoid timeouts.
Long Web pages
An image is captured for each scrolled viewport for later building the fullpage version of the screenshot results. There is a limitation on the number of viewports that the system will scroll. This is due to memory restrictions for storing every image necessary during the process, as well as the fact that some web pages will continue adding content to the bottom of the page and theoretically never reach the end. The current limitation is 25 scrolled viewports for desktops and 40 viewports for mobile devices. If the web page surpasses this limitation, the resulting fullpage screenshot will be cut short, or may even fail to complete successfully.
Growing or shrinking Web pages
A web page’s use of JavaScript to insert, remove, or rotate content will at times result in the overall height of the page to grow or shrink accordingly. The ScreenshotDriver is aware of this and checks for changes as the page is scrolled and screens are captured. This should not cause the test to fail, but may cause the final fullpage result to have seams, meaning, you can see where two images were appended together and the page shifted up or down between screen captures such that the fullpage screenshot does not look continuous.
Rotating content and images
Some web pages are programmed to use JavaScript, Flash, Silverlight, or other methods for dynamically changing content. A common example is a rotating image that changes every few seconds. As the page is scrolled for screen captures, the rotating image may have changed between one screen capture and the next. When these two screen captures are pasted together, the resulting fullpage screenshot will show this discrepancy.
Fixed-position elements
Some web pages are programmed to use "fixed" position layers such that an HTML element remains in its same position within the viewport as a page is scrolled. A common example is a custom toolbar for interacting with the website at the bottom of the page. Since fullpage screenshots are created by scrolling the page, getting screen captures, and pasting the final images together, the result will show this fixed position layer several times down the image. We have included an algorithm to avoid this issue and automatically hide fixed elements (though it used to be an advanced option).
Web page rendering
There are cases where a web page is loaded and ready, the browser reports the document as "complete", but the browser is in fact still rendering the style sheets and painting images. There is also the case where JavaScript calls are made to perform other layout tasks on the page such that, technically, the rendering of the page has not finished. In this case, the resulting screenshots may make the web page layout appear broken, yet a live test of the web page will show the layout correctly. The simple fix for this is to add a delay to the screenshot test for the length of time the web page needs to finish the rendering process.
Framesets & page scrolling
Though fewer in number these days, some web pages are developed using HTML frameset elements and the resulting fullpage screenshot may not look like a scrolled version of the page. If the window.scrollTo() method in JavaScript does not cause the page to be scrolled, the system does not inspect the frames to see which one could or should be scrolled. The fullpage screenshot will look the same as a windowed screenshot.
Iframes
Most iframe elements on a web page are not a problem for the ScreenshotDriver, however, they have been known to cause issues with the browser signaling that the page is loaded, since all frames on a page must return this status before this signal occurs. The ScreenshotDriver has a few catches for this case and attempts to move forward after a page load timeout but iframes can cause the screenshot test to fail in some instances, especially with Internet Explorer tests.
Browser notices
Since the ScreenshotDriver runs tests against actual browsers, some results will show browser messages and confirmations such as saving passwords, language translations, permission to continue, https errors, and more. These can be "pop up dialogs" (mostly older browsers) that prevent interaction with the browser or "information bars" (newer browsers) that are just visual obstructions. Even though the ScreenshotDriver makes attempts to handle these cases across the wide variety of browsers offered for testing, some screenshot results will show these dialogs and messages. This is both good and bad. On one hand, it’s not exactly helpful in verifying the layout of your web page, but on the other hand, it might be good to know that the particular browser will display this type of message to users on this page.
Login forms
To get screenshots of a web page that requires form-based authentication, a user creates a login profile when creating a new screenshot test. There are three HTML selectors, or "locators", for finding the login fields on the page: the username field, password field, and submit button. The ScreenshotDriver uses these references to locate the input fields on the page, plugin the relevant values, and then click submit. Here are a couple of concepts to be aware of for this process to work as expected.
-
The HTML for the input fields on the login form should be the same across all browsers and platforms being tested.
-
There is more than one way to specify the element on the form: id, name, XPath. If a browser has trouble logging in, try another locator type.
-
The login button should submit the form and load a new page.
-
You can specify a separate login URL for where the login form can be found if not available on the page requested for screenshots.
-
If the login process takes the browser to a different URL, the originally requested URL will be reloaded. Example: the screenshot test URL is http://mypage.com and after login the page is at http://mypage.com/login_successful, the ScreenshotDriver will reload http://mypage.com before a screenshot is performed.
Basic or HTTP authentication
Depending on the setup of directories on the website and the browser's behavior, screenshots may fail or show the username/password prompts for sites with folder protection. This usually occurs when there are .htaccess files in subdirectories with different rules, calls for redirects, or resources requested outside of the authorized folder, in which case the browser will prompt for the username and password multiple times, causing the ScreenshotDriver to be blocked and the test to fail.
Invalid SSL certificate
When a user clicks Take Screenshots for a new screenshot test on our website, the URL is checked to ensure a proper status is returned. In the case of SSL Certificate issues, a warning is displayed containing the nature of the error with option for the test to continue, disregarding the error. Depending on the configuration of the browser, the screenshots will fail or succeed. We've attempted to configure each browser to be lenient with these certificate errors, but some cases cannot be bypassed. If you feel you are getting certificate errors in the browser when you should not, verify your SSL and contact us with details.
Please contact us if you did not find help with an issue you have listed here. We are always looking for feedback to improve the screenshot service and answer questions you may have.