Hacker News new | past | comments | ask | show | jobs | submit login
Firefox 41 can screenshot a single DOM element (hacks.mozilla.org)
429 points by liotier on Sept 30, 2015 | hide | past | web | favorite | 79 comments

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

[0] http://threadshots.com

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

And sometimes doesn't stop on debugger statements.

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 :(

I save them in `/tmp` and I don't need to worry about them ever again.

Why isn't the clipboard a special-case file in the first place?

This sounds like a reasonable feature request, bug tracker item.

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.

So in other words it doesn't work if the element has children that are transformed (tested that). Still useful though

And if there are non-child elements positioned to overlap with this one, presumably they get captured too?

What happens if there are elements below the one you're screenshotting by z-index?

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.

Are there any plans to make this available through a Javascript API? With appropriate security warnings of course.

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.

The clipboard api only includes 'cut' and 'copy' commands. There is no way (except via extensions) to access the clipboard.

Thanks for the correction!

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.

No, just the right edge. It also ignores the page zoom setting and screenshots the element at 100%. (User styles set by Stylish do apply, though.)

I think this has to do with some DPI issues- I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1209773 about general lack of smarts about DPI for this feature, hope that fixes it.

Related: The Print Edit add-on for Firefox, which has been doing something similar for over 5 years, and which I think also acts on DOM elements:


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.

<div id="mydiv"><iframe src=facebook.com...

screenshot("#mydiv"), send to my server

would need some security handling, at least.

There was a DOM2Canvas library at some stage, though it wasn't perfect and it couldn't render images (for security reasons).

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.

I thought we finally got a JS api to take a screenshot of the dom. Damn!

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.

Another one that comes to mind is "Are you blocking ads?", although I should probably stop before I give them any more ideas...

Sites already appear to be able to detect that.

https://www.npmjs.com/package/rasterizehtml renders HTML into the browser's canvas.

For now maybe this is good enough: https://github.com/niklasvh/html2canvas

Oh yeah, me too...

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.

navigator.onLine feels like it should not have been camelcased

Ah, but back in the days of IE4 (when this property was introduced), "online" wasn't a word yet.

I feel like I'm missing the punchline here.

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

Here's what google ngram says: https://books.google.com/ngrams/graph?content=online%2Con+li...

I stand corrected! Thank you.

Right, otherwise it would have been just AO, not AOL.

As best I can tell, AOL was named America Online (no space or camelcase) in 1989.

I am not even a webdev, but this feature makes me so giddy with joy.

I wrote a Chrome extension to do this awhile back https://github.com/tlrobinson/element-capture but newer versions of Chrome broke it at some point. I'll try to get it updated.

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.

Amongst the other features - Being able to download the HAR file is quite useful.

Chrome already supports it.

I had to use the Firebug FF extension for downloading them previously. Now it is easier.

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?

[0] http://insite-feedback.com

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

Well, it could ask for permission - like the Fullscreen API, or the HTML5 Notifications, or...

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.

Is this cool or what? I just uninstalled the "Screengrab!" extension I've been using for years.

I am sad it saves raster PNG files rather than something scalable like SVG or PDF. SVG seems like an easy win.

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.

Leaving the fonts scalable while rasterizing everything else would be fairy doable, yes.

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.

This is cool though. Hope it can screenshot a pdf image.

This is s small, but awesome feature.

That'll save me from typing ⌘+^+⇧+4 and having to manually align the box.

Isn't it just ⌘+⇧+4?

Adding Control puts it in the clipboard instead of a file on the desktop

Yep. Then I can paste it into Imgur, the GIMP or Twitter.

I have this script bound to cmd-shift-6: https://github.com/jomo/imgur-screenshot

next thing you know, they will say that it belong into an extension... but Firefox is still my favorite

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.").

Safari 9 has the lowest score on HTML5test and the ES6 compat table. To make matters worse, Safari 9 isn't even out yet.

Safari 9 was released yesterday (September 30) alongside OS X El Capitan.

That's fantastic guys. I mean, think about it. Screenshot a . single . DOM . element. Upvote this. Oh my god I think I should just get some sleep.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact