Applitools Eyes Not Capturing a Full Webpage in Chrome: Fixes

If an Applitools Eyes checkpoint in Chrome shows only the visible area, first confirm the checkpoint requests a full-page capture. Then check whether the page scrolls inside a nested element, whether lazy-loaded content has appeared before capture, and whether fixed elements are interfering with stitching. These are distinct causes; the issue is not necessarily a Chrome defect.

1. Confirm that the checkpoint requests a full-page capture

A regular checkpoint may capture only the viewport. Full-page capture must be enabled through the API supported by your Applitools SDK and version. The current Playwright integration documentation shows fully: true on eyes.check():

await eyes.check("Full page", {
  fully: true
});

This is Playwright-specific syntax. Do not copy it into Selenium, Cypress, WebdriverIO, Java, or another integration. Find the equivalent option in the documentation for your SDK and version. If you already request a full capture, continue through the checks below.

Source: Applitools Playwright integration.

2. Find the element that actually scrolls

Eyes normally attempts to scroll the document or body. Some applications instead place the content in a panel with its own scrollbar. In that case, scrolling the document does not reveal the rest of the panel, so a full-window capture may look truncated.

Open Chrome developer tools and inspect the panel that contains the missing content.
Check whether the candidate element can scroll: in the Console, select it and compare its scrollHeight with clientHeight. A larger scrollHeight indicates overflow content.
Set the element’s scrollTop to a positive value and confirm that the panel content moves. Restore it to zero afterward.
If that element is the scroll root, configure it as the scroll root using the API supported by your Eyes SDK.

Applitools documents scrollRootElement(...) for this case. The selector and surrounding checkpoint setup depend on the integration, so use the matching SDK documentation rather than assuming one snippet works everywhere.

Source: Determining the Scrollable Element to get a Full Page Screenshot.

3. Load lazy content before the checkpoint

Pages often load images, cards, or other content only when a visitor scrolls near them. If Eyes determines the page length before those elements load, the final image can omit them or stop too early. Scroll down in increments, allowing each section to load, then return to the top and take the checkpoint.

// Playwright example: scroll through the document in viewport-sized steps.
// Adapt the wait to the page's actual loading behavior.
await page.evaluate(async () => {
  const step = Math.max(1, window.innerHeight);
  const pause = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

  for (let y = 0; y < document.documentElement.scrollHeight; y += step) {
    window.scrollTo(0, y);
    await pause(250);
  }

  window.scrollTo(0, 0);
});
await page.waitForTimeout(500); // Replace with a meaningful readiness condition when available.
await eyes.check("Full page", { fully: true });

This is a general Playwright preparation example, not an Applitools-specific readiness detector. A fixed delay can be too short on a slow page or unnecessarily long on a fast one. Prefer waiting for a known image, content selector, or application-ready state when the page exposes one. Scrolling directly to the footer can miss content whose load is triggered only as each intermediate section enters view.

Source: Screenshot is missing content due to lazy loading.

4. Choose a capture mode that fits the page

Fixed headers and floating bars can appear repeatedly in captures that scroll and stitch viewport images. Applitools describes CSS mode as an option for avoiding repeated fixed-position elements; scroll mode uses standard JavaScript window scrolling. If the selected mode produces missing sections or incorrect stitching, try the alternative mode when it is supported by your SDK and test configuration.

The available setting can depend on account and Ultrafast Grid configuration. Applitools notes that the Screenshot Capture Mode option is displayed when Ultrafast Grid is disabled or the user lacks a license for it. Check the settings and documentation for the configuration you actually use.

Sources: Defining Eyes Visual AI Settings and Screenshotting.

5. If the target is a scrollable region, capture that region

Sometimes the goal is not a screenshot of the entire browser page but a complete capture of one scrollable panel. In that case, checkpoint the region and enable the SDK’s full-capture option for that region. The fully() spelling in Applitools’ region guidance is specific to the SDK example; check your language and version before using it.

Source: CheckRegion in scrollable elements.

Diagnosis checklist

Only the viewport appears: verify the checkpoint’s full-page option and confirm the correct SDK syntax.
The image stops at a panel boundary: test whether a nested element, rather than the document, scrolls; configure the actual scroll root.
Images or sections are missing: scroll through the page to trigger lazy loading, wait for relevant content, return to the top, and capture.
Headers or bars repeat: try CSS capture mode if the integration and account configuration expose it.
A panel is the intended target: use a region checkpoint with full capture for that region.
Stitching remains incorrect: try the alternative capture mode and confirm whether the page changes height while loading.

Common errors and fixes

Symptom	Likely cause	What to do
Checkpoint ends at the bottom of the viewport	Full capture was not requested, or the wrong SDK option was used.	Enable the full-page option documented for the installed SDK and version.
Only part of an app panel appears	A nested element owns scrolling.	Identify the element whose `scrollTop` moves the content and set it as the scroll root.
Lower images are absent	Images load only when scrolled into view.	Scroll through the page in increments, wait for the content, return to the top, then capture.
Page height seems to change during capture	Lazy content or asynchronous sections are still loading.	Wait for a meaningful page-ready condition and trigger scroll-based loading before the checkpoint.
Fixed navigation appears more than once	Scroll-and-stitch behavior repeats fixed-position elements.	Try CSS capture mode if supported by the current configuration.
A region is complete but the page is not	The checkpoint targets a scrollable region instead of the full browser window, or vice versa.	Match the checkpoint target to the intended output and enable full capture for that target.
Document scrolling works manually but not in the test	The application may use a different scroll root, or the capture mode may not fit its layout.	Inspect overflow containers and try the appropriate scroll-root and capture-mode settings.

Performance, reliability, and cost considerations

Full-page captures take more work than viewport captures because the page may need to be scrolled and stitched, and lazy content may require additional preparation. Keep the test deterministic: wait for a real page-ready signal where possible, use consistent viewport and device settings, and avoid arbitrary long delays that add runtime without ensuring readiness.

Pages with infinite scrolling need special handling because their height may keep increasing. Decide which content boundary the test should cover, scroll until that boundary is loaded, and avoid treating an unbounded feed as a stable full page. Animation, live data, and rotating banners can also change between runs; stabilize or disable them in the test environment if they cause visual differences.

Each additional scroll and wait can add test time. Use full-page capture only for checkpoints that need below-the-fold coverage, and capture a specific region when the test is about one panel. The research sources do not provide a universal runtime or price figure for these fixes; check your current Eyes plan and test setup for cost implications.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF. Its clean-shot options accept cookie and consent banners like a visitor, then remove 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server includes tools for AI agents to take screenshots, get page information, and capture PDFs.

For a full-page WebP shot, use this cURL request (replace the URL and API key):

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -d full_page=true \
  -o shot.webp

See the ScreenshotNeo API documentation for authentication and the supported parameters. The API also accepts the parameter names used by other screenshot APIs.

Here are equivalent request examples in Python and Node.js:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://stripe.com",
        "full_page": "true",
    },
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
  full_page: 'true'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Confirm the full-page parameter spelling in the docs for your request. ScreenshotNeo also supports selector capture, CSS and JavaScript injection, custom waits, device presets and viewports, cookies and headers, request blocking, caching, async jobs, and bulk capture. Free includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots, and every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.

FAQ

Is this always a Chrome bug?

No. The documented causes include a checkpoint that does not request full capture, a nested scroll root, lazy content, and capture-mode behavior. Diagnose which applies to the page.

Should I use the Playwright `fully: true` option in every SDK?

No. It is the syntax shown for the Applitools Playwright integration. Other SDKs have their own APIs and version-specific behavior.

Will scrolling to the bottom trigger all lazy-loaded content?

Not necessarily. Some pages load content as each intermediate area enters view, so scroll down in steps and allow loading before returning to the top.

When should I capture a region instead of the whole page?

Use a region checkpoint when the test concerns a particular scrollable panel. Use a full-window checkpoint when the expected image should represent the browser page.