[cmgriffing]

Quick note: when trying to do full page screenshots, Chrome does a screenshot of the current view, then scrolls and does another screenshot. This can cause some interesting artifacts when rendering pages with scroll behaviors.

Firefox does a proper full page screenshot and even allows you to set a higher DPS value. I use this a lot when making video content.

Check out some of the args in FF using: `:screenshot --help`

[wereHamster]

That's not the behavior I'm seeing (with Puppeteer). Any elements positioned relative to the viewport stay within the area specified by screen size (eg. 1200x800) which is usually the top of the page. If the browser would scroll down these would also move down (and potentially appear multiple times in the image). Also intersection observers which are further down on the page do not trigger when I do a full-page screenshot (eg. an element which starts animation when it enters into the viewport).

[genewitch]

bravo for puppeteer, i guess? "singlefile" is the only thing i've ever seen not do weird artifacts in the middle of some site renders, or, like on reddit, just give up rendering comments and render blank space instead until the footer.

anyhow i've been doing this exact thing for a real long time, e.g.

https://raw.githubusercontent.com/genewitch/opensource/refs/...

using bash to return json to some stupid chat service we were running

[ranger_danger]

Where would you type that command in?

[pavel_lishin]

Firefox developer console.

[xg15]

I mean, if you have some of those annoying "hijack scrolling and turn the page into some sort of interactive animation experience" sites, I don't think "full page" would even be well-defined.

[sixothree]

Pretty sure this refers to sticky headers. They have caused me many headaches when trying to get a decent screenshot.