1346651 - Add the ability to capture more than just the visible tab region with browser.tabs.captureVisibleTab.

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, enhancement)

Description

[Thomas Wisniewski]

This is something Blink addon devs have long been requesting [1], and I'm not seeing any specific reason to not allow it other than potential memory-overflow type issues. There are work-arounds which are imperfect, as noted in [1], so I figure if there is a screenshot facility already, it might as well be more useful. I'm just not 100% sure what the best API would be:

> browser.tabs.captureVisibleTab(windowId, { region: {top:int, left:int, width:int, height:int }});
> browser.tabs.captureVisibleTab(windowId, { region: {top:int, left:int, bottom:int, right:int }});
> browser.tabs.captureVisibleTab(windowId, { fullTab: bool });

The first option would of course allow users to specify the full tab by passing in the approprate values, so perhaps it's a more useful option:

> let doc = document.documentElement;
> browser.tabs.captureVisibleTab(windowId, { region: {top:0, left:0, width:doc.scrollWidth, height:doc.scrollHeight }});

I've written a simple patch for my own internal work which adds the "fullTab" API, and don't mind extending it to handle the general-purposes cases and adding tests.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=45209

Comment 1

[Thomas Wisniewski]

Actually, I didn't see bug 1310318. Now that that's in, this may not be of much value (given that the current implementation of captureVisibleTab uses canvas.drawWindow anyhow).

Comment 2

[Kris Maglione [:kmag]]

This is impracticable. You'd need to use a content script to scroll and repeatedly drawWindow to a canvas.

Comment 3

[Thomas Wisniewski]

Not that I mind the WONTFIX, but why is it "impracticable"? It's no different from just using canvas.drawWindow manually; you'll still run into the same problems one way or the other. I do agree that it's *obsolete* though, given the support for drawWindow (but that's also true for captureVisibleTab in general).

In case anyone reads this while trying to implement a screenshot-taker, note that you need to consider whether you want to trigger onscroll handlers or not. If not, use drawWindow's parameters to take tiled screenshots. If so, you may want to wait until the onscroll handlers have done their work before you capture the next tile. And either way, you may end up running into problems with animations/videos changing in the time between tile snapshots, so don't rely on this method giving you a pixel-precise result. (We would need an API to "freeze" all activity in a tab before that becomes practicable).

Comment 4

[Kris Maglione [:kmag]]

drawWindow only allows capturing the visible area of a window. The manual scrolling fallback is essentially a hack, but some tools do it anyway.

Comment 5

[Thomas Wisniewski]

>drawWindow only allows capturing the visible area of a window.

If it's intended to be restricted in that way then we should file a bug, because this code snippet is working fine for me from a content script to grab the entire page including everything "beneath the fold", rather than just the viewport/region currently visible on-screen:

  let w = document.documentElement.scrollWidth;
  let h = document.documentElement.scrollHeight;
  ctx.drawWindow(window, 0, 0, w, h, "#fff");

I can also change the x,y,w,h parameters I pass in to take a screenshot of just a tile of the screen, also not limited to what's currently displayed on-screen.

Of course, if the page waits to dynamically inject content as the user scrolls, then the screenshot won't show anything, but that may not be desirable anyhow (it's not what I wanted in my debugging addon, for instance).