This is an awesome feature, I love how browser dev tools have been continuously improving in recent years. Taking screenshots of DOM elements has been something I've dedicated a lot of time to recently. Most of the extensions available for doing this rely on taking a screenshot of the available viewport so in order to capture larger DOM elements they need to scroll around taking repeated screenshots (which can be kind of frustrating if it takes a long time).
We just launched a browser extension [0] for taking screenshots of Facebook posts and we were basically tasked with accomplishing the same thing. We approached it by fetching all of the external resources and inlining them as data URIs, wrapping the HTML in an SVG element, drawing the SVG to a canvas, and finally extracting the data URI for the canvas. It works really well and eliminates the jitter/delay associated with scrolling around to capture multiple screenshots.
Good thing we also automate the anonymization of private information or this announcement might have obsoleted us on Firefox :-).
> Most of the extensions available for doing this rely on taking a screenshot of the available viewport so in order to capture larger DOM elements they need to scroll around taking repeated screenshots (which can be kind of frustrating if it takes a long time).
Or when parts of the page dynamically reposition themselves as the page scrolls. The worst.
> I love how browser dev tools have been continuously improving in recent years.
Meanwhile Firefox still displays all JavaScript sources as a single list in the debugger without any sort of folder nesting, making it unusable as a development tool for non-tiny JavaScript apps.
Taking screenshots of the full page or individual elements was also possible before via Tools -> Web Developer -> Developer Toolbar (Shift + F2)... and then using the `screenshot --selector ...` command.
You also have access to part of this functionality via the non-standard drawWindow method:
Screenshotting DOM elements is almost perfect, except for one thing. Once you take a screenshot, a file save prompt is opened, so unless I missed something, you can't save it in the clipboard.
Which is a shame, it would be a killer thing if you could screenshot a DOM element, save in clipboard, and copy&paste in gmail or slack. I don't want to keep littering my desktop (or wherever) with tons of jpgs :(
How does this work with elements with a semi-transparent background? Will the resulting screenshots also be semi-transparent, or will they contain portions of the element beneath?
(I work for Mozilla) It captures the page cropped to the bounding box of the element, so any background content would also be captured. The results would not contain transparency.
You would see the element under it assuming it's possible. What this does is finds the bounding box cords and takes a full page screenshot and crops it to that region.
If you want to render an element with transparency, you have to seperate it from the page and render it yourself with ctx.drawWindow(window, x, y, dx, dy, "transparent") to a canvas
My clipboard often has private stuff in it, unrelated to the site I'm visiting.
I don't like the idea that clicking on a button (like "add comment" on HN) would gives a site potential access to what's in my clipboard, without any indication or affirmation that that's ok.
It feels like something that will be exploited, if only by the curious.
Someone in the comments says "I was doing this on a normal 1600×900 monitory and was still having issues with the right edge being cut off a little." I have the exact same problem on a 1600×900 ThinkPad W530, running Windows 8.1 at 100% DPI. Screenshots have their right edge missing.
Are they also missing the bottom edge? I ask, because I can kind of imagine a reason for such behavior. Half-open ranges let you just paste everything back together to get the original. I seem to recall the CSS box model just sort of arbitrarily cuts diagonally across overlapping borders...
This is total speculation. I could be way off-base here.
It allows you to edit the elements in a page before printing or saving (as PDF, JPG, etc.). You can remove them, alter them, reformat them, inspect them, print a single element (like FF 41 will do) and do much more. It's an amazingly sophisticated add-on that I'm underselling; I encourage you to read the link or simply try it. It's a wonder to use and the most impressive add-on I've seen.
Clicked on it hoping that this is a new browser feature that I can access from the web page via JavaScript... but this is just a dev tool. I hope that this feature will eventually appear, currently taking snapshots from the client side is a major pain point.
Multiple browser engines have the ability to do this, but every time I've asked there's been no intent to ever expose it to webpages/webapps, just extensions.
That sounds like it'd be very easily abused for browser fingerprinting and DRM-ish things (do you have font X installed? Are you using custom CSS? Any extra things added by particular extensions?)
Most of those types of things can be used for fingerprinting currently with JavaScript w/o need for screenshot rendering. Anything that injects into the page DOM can be detected and some timing attacks are possible.
The main issues that I think are important to consider are revealing browser history (visited links) and cross-frame information (like <iframe>). Modern browsers already have protection in these areas.
We have to rely on JS based rendering into a Canvas element for http://insite-feedback.com - and I would love to improve that process with a direct API :/
Well, maybe sometime soon. What would you use the direct API access for?
I wish it weren't hidden away in the inspector menu... I'd love to point non-devs at it! Maybe a(n off by default) screenshot toolbar button that let you point at the page / element you wanted, rather like the Command-Shift-4 window selector in OS X.
Hasn't the developer command line supported this since...well at least two years? I've used it hundreds of times. Super handy. I guess I'm glad it's in the UI now.
"online" is accepted as a word now, but the navigator.onLine property was added in IE4 (released in 1997) back when "on line" was the conventional spelling.
As far as I'm aware (from personal experience), "online" has been the common form when talking about computers since at least the 1980s, if not before.
But maybe whoever added that particular property to IE4 wasn't familar with common (in computer circles) usage...
The screenshot api has been in Firefox since v4 I think. I've been using this addon (https://addons.mozilla.org/en-US/firefox/addon/firecaptor/) to capture element of a page. It works like the inspector tool when selecting an element.
I was shocked for a second that the product I've been working on for the last year [0] has become obsolete over night... But luckily its not the case, phew :D
We are creating screenshots of websites directly in the browser to enable users to give easy feedback to their web agencies - and we also implemented a cropper to make this easier for the people.
Does anybody know if there are plans to offer access to the screenshot library via a JS API somewhere soon in the future?
> Does anybody know if there are plans to offer access to the screenshot library via a JS API somewhere soon in the future?
It's almost certainly not going to happen, due to security concerns. There previously had been attempts to toss a DOM screenshot into a WebGL texture but that was also found to be vulnerable to timing attacks that could reveal private data.
It's a hard permission to give safely, because once the application has permission to take screenshots there are tons of ways for it to get third-party content into the viewport and capture it.
> Does anybody know if there are plans to offer access to the screenshot library via a JS API somewhere soon in the future?
Like another user said, one could wrap the HTML DOM tree into a SVG element, and then render that to an image. So from within Javascript, this could be done in a few lines of code, I suppose. I haven't tried it though.
Creating a raster image can just use the normal painting codepath, since that's what a browser has to do anyway to get pixels up on the screen.
Encoding stuff in SVG, on the other hand, requires adding a lot more plumbing (and some parts of it, like element() backgrounds it's not immediately clear how you'd do without rasterizing things).
Perhaps I am wrong in assuming, but I thought it was effectively converting to something like a <canvas> behind the scenes anyway, simply for scalability/zoom purposes, in which case it just needs to have a node-focused clipping area, even if the all other elements remain rendered outside of the clipping area (though most could be discarded, as they are off-screen). Even if untrue, simply substitute Postscript for SVG in my comment... Firefox can clearly print an <html>-rooted DOM node. Even if they just had a "print DOM node" item, the result could be passed to the normal printing path to get something close to a .PS. Users often have Print-to-PDF software already.
Printing a specific node is a major use-case, and for that text needs to still be as scalable fonts.
Shameless plug: If you're interested in this functionality, but want it in all browsers without needing any plugins, check out my start up BugMuncher - https://www.bugmuncher.com
Fetching the current page over the network from a similar browser is not exactly the same as taking a screenshot from the user's actual browser instance...
You are correct sir, but until this new firefox screenshot function is available as a JavaScript API in all browsers, it's the closest anyone can get. And there will always be stragglers with older browsers to account for.
It's also worth mentioning that because BugMuncher uses a big farm of Selenium servers, it's pretty rare that it can't take the screenshot in the exact same Browser / OS as the user. And in those scenarios, BugMuncher uses a scoring algorithm to find the closest match available.
Wait, so Firefox just added clipboard copy support one day ago, and everyone in the other thread about clipboard.js was already calling Safari "the new IE" for this reason?
No, clipboard support has been in Firefox for months. It was enabled for web pages over the summer.
It's unfair to really ding any browser for not supporting this. It's not yet properly specced ("This spec is incomplete and it is not expected that it will advance beyond draft status.").
We just launched a browser extension [0] for taking screenshots of Facebook posts and we were basically tasked with accomplishing the same thing. We approached it by fetching all of the external resources and inlining them as data URIs, wrapping the HTML in an SVG element, drawing the SVG to a canvas, and finally extracting the data URI for the canvas. It works really well and eliminates the jitter/delay associated with scrolling around to capture multiple screenshots.
Good thing we also automate the anonymization of private information or this announcement might have obsoleted us on Firefox :-).
[0] http://threadshots.com