Discussion: page.screenshot changes in v2.0.0

Per upstream Chromium changes, page.screenshot now clips elements to the viewport as of Puppeteer v2.0.0.

https://github.com/GoogleChrome/puppeteer/commit/81d26002361f2485d4ae8a9758be25e65d4c1c01 rolled Chromium, and https://github.com/GoogleChrome/puppeteer/pull/5079 added a test based on the new behavior.

The good news is that with this change, document and overflow scroll clipping now work the same. It fixes issues with fixed-position headers, such as the bottom-sticking support and cookie banners on https://www.theguardian.com/us which would previously render in the middle of a screenshot. Generally, it makes page.screenshot work exactly like Chrome does (literally capturing a screenshot), rather than producing a result Chrome would not render in real scenarios.

Puppeteer scripts that relied on the old behavior can be updated to resize the viewport before calling page.screenshot.

But, it could be that people relied on the old behavior in some way for which the above workaround doesn’t help. This issue can be used to collect such use cases and identify alternative implementations.

[trotzig]

Hi there! 👋

First of all I’d like to stress how much I appreciate the work that you are doing. Puppeteer is by far the most developer-friendly and efficient way of automating a browser. 👏

I run Happo.io, a screenshot testing service. We do cross-browser testing with Chrome being one of the targets. Other browsers (like IE11, Edge, Safari, etc) we control via Selenium but Chrome is controlled via Puppeteer.

Most of our users have test suites that consist of individual components where few span more than the height of the viewport. But there are cases where components are taller than that, and we rely on Puppeteer giving us full screenshots of the components. Some of our users have full pages in their test suites, although that’s not the most common setup.

The workaround suggested where the screen size is adjusted before taking the screenshot isn’t always a good solution, for a few reasons:

• elements styled with a vh unit in CSS will probably not look right. Imagine a large heading (hero style) which is made vertically centered through a 100vh flexbox container.
• fixed/sticky elements might not be in the right place (as mentioned in the original comment)

Viewport-cropped screenshots is a problem in other browsers as well. With IE controlled through Selenium, we only get the viewport back in the screenshot. The workaround we have implemented there involves stitching together a full screenshot by scrolling through the page. That workaround has the added side-effect of making sticky/fixed elements appear several times, which we work around by hiding them after they’re first seen.

We could potentially adopt the “stitching” workaround described above for Chrome as well, but it would affect performance negatively. Since Happo is a tool people use in CI, and people don’t like waiting for CI, we have a tight budget for taking screenshots. Some of our users have 10000+ examples to screenshoot for each CI run and the screenshot phase is one of the slowest (50-250ms) in the Chrome runner.

I don’t have enough context to know if supporting the old screenshot behavior is even viable, but if I could be the PM here I’d love to see that happen! 😃

[trotzig]

Good news – the above referenced chromium bug has been fixed and merged. To get screenshots that aren’t cut off at the viewport edge you need to set the blink flag mainFrameClipsContent=false:

await puppeteer.launch({
  args: [
    '--blink-settings=mainFrameClipsContent=false',
  ],
});

I’m running through some regression tests on happo.io and it looks like things are working well and that the old behavior of capturing content outside the viewport is back again. 🎉