Giters

ulixee / unblocked

A suite of tools for protecting the web's open knowledge.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

takeScreenshot fails to work when passing in a rectangle outside the viewport

GlenDC opened this issue · comments

commented

I can take a screenshot as follows:

const mySel = await hero.querySelector('#myId');
const screenshotRectangle =
   // eslint-disable-next-line @typescript-eslint/no-explicit-any
   (await mySel.getBoundingClientRect()) as any;
screenshotRectangle.scale = 1;
const buffer = await hero.takeScreenshot({
   format: 'jpeg',
   rectangle: screenshotRectangle,
   jpegQuality: 100,
   fullPage: true,
});

This gives however the full page, ignoring the given rectangle.
If I however leave off the fullPage (which is what I tried first), I get an error which states
that the given rectangle is outside the viewport...

https://github.com/unblocked-web/agent/blob/main/core/lib/Page.ts#L770-L773 that's the assert that I get apparently.
two observations there:

So given the second observation I think we can even just drop that assert. But if you do want to support < 87,
then I suppose you would want to also support overriding the screen dimensions based on a given rectangle, rather
then only doing it for fullPage?

According to @blakebyrnes we might need to resize to fit the element size if it’s that big,
see on Discord for his original message: https://discord.com/channels/966293220780806174/966293220780806177/1032432492822667305

commented

Thanks @GlenDC. As per Discord, that flag does not work as you'd hope, which is why we're doing all the work to resize the screen to capture beyond the viewport. If you find that newer versions have finally added support, please report those findings here and we'll figure out what to do.

We have a test that takes a clipped rectangle smaller than the viewport, so it seems there are two potential issues here:

  1. An element out of view. I do NOT think we should scroll the window here for you. Seems you should do this yourself.
  2. If an element is larger than the viewport, it's throwing that assertion. I agree we should experiment in this case to see what happens if we simply remove that assertion. Otherwise, we probably need to do the same thing we do on full screen
commented

An element out of view. I do NOT think we should scroll the window here for you. Seems you should do this yourself.

I do not agree, @blakebyrnes. From a UX POV there should be no difference in how to use full page Vs giving a rectangle. It's not as if you expect full page to be scrolled (What would that even mean).

For me giving a rectangle is like taking a cropped full page. It will be a pretty horrible UX (and what would even be the advantage for the user) that they first would have to scroll. The other option is that I would need to do the cropping outside, but that seems a bit odd.

So I really strongly urge that the experience between full page and rectangle, which IMHO is just a cropped version of full page.

commented

I might have stated my point poorly. I do not think the mouse should scroll the page automatically here - I'm not opposed to getting the cropped area a different way. If I'm interacting with the page, and take a rect screenshot that is off-page, moving my mouse and the viewport to that location is not what I would expect. It's adding behavior that I can't control, and very likely changes the state of the page (eg, hovered elements).

That said, I would be more in favor of the full page screenshot and then doing some kind of crop out of it.

commented

That said, I would be more in favor of the full page screenshot and then doing some kind of crop out of it.

You mean that if you use the Rectangle property that it would start with a full page, and than crop it?