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! :)

I work on the blink paint code and was involved in this change (it was part of BlinkGenPropertyTrees). The previous behavior was more of an accident and we didn't really have a unified solution for position: fixed/vh units/etc. For example, not changing the viewport is good for hero elements but bad for pages where the background behind the text is viewport sized.

@trotzig , are there pages that you could screenshot before but no longer can using stitching and resizing?

Hi @progers, thanks for the fast reply!

I built Happo with @trotzig and I currently work at Airbnb where we are using it extensively.

are there pages that you could screenshot before but no longer can using stitching and resizing?

Stitching (I assume by scrolling and taking multiple screenshots) isn't very good on pages where there is anything sticky or fixed position, or anything that is triggered by scrolling (e.g. IntersectionObserver, lazy loaded content).

Resizing the viewport to accommodate the entire contents isn't very good for anything that uses height-based media queries (e.g. a list that compacts down on shorter viewports), resize events, or lazy loaded content. It probably also would throw off elements styled with vh on really tall pages and other things of that sort.

Stitching and resizing also don't work for elements that begin positioned below the viewport and then animate in--Happo will freeze the animation at the first frame and we currently are able to capture these types of elements just below the viewport.

@trotzig , are there pages that you could screenshot before but no longer can using stitching and resizing?

I found that few pages look right when using the resizing approach. Developers tend to assume that the height never goes above something like 1600px. Take https://api-platform.com/ and https://connect.garmin.com/ for instance, they both have content that will be 100vh tall.

Stitching is more robust, but it poses a number of challenges as well. Sticky content will be visible in each chunk, parallax effects make backgrounds look wrong, infinite scroll lists make it hard to know when you're done, content can shift position when lazy-loaded (e.g. with the use of IntersectionObserver).

While I understand that the old behavior was more of an accident, it was an accident that made our work a lot easier. :)

We could investigate whether enabling the MainFrameClipsContent setting before taking a screenshot (on the Blink side) solves the problems.

We could investigate whether enabling the MainFrameClipsContent setting before taking a screenshot (on the Blink side) solves the problems.

@mathiasbynens It's almost a year since this was opened. Is there any update on this? Clipping below the fold is hugely missed. I'm still running a version of puppeteer that is older than this release because without that a lot of my use cases break.

@whoisjuan Star https://bugs.chromium.org/p/chromium/issues/detail?id=1003629 to get updates.

@whoisjuan Star https://bugs.chromium.org/p/chromium/issues/detail?id=1003629 to get updates.

Following. Thanks.

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. 🎉

We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days.

We are closing this issue. If the issue still persists in the latest version of Puppeteer, please reopen the issue and update the description. We will try our best to accomodate it!