The interesting thing here is that you can set the iframe size to a regular desktop-like size, and then use CSS3 transforms to scale the rendered page down to thumbnail size.
This is so totally messed up. Having an entire DOM with all the associated scripts running live, just for a thumbnail. What if you want to show a dozen of them? What if the user wants to save the image to their machine?
We solve this by taking server side screen shots (currently using slimerjs). We used HTML2Canvas in the past, but it wasn't reliable enough.
It would be great if there was a built-in browser method though, to just get a bitmap of the screen in Javascript. I've heard about security considerations in the past — a prompt for access would not be a problem in our case.
Just tested this out, IE and Firefox will only load each page twice, it won't re-load the original page. Chrome goes a bit deeper, it will load each page twice, but then stops.
>It would be great if there was a built-in browser method though, to just get a bitmap of the screen in Javascript.
I've used webkit.js (https://github.com/trevorlinton/webkit.js) to implement a client-side save-chart-to-image feature in an web app. Not really sure if I'd currently recommend it, but the strategy has promise if developed on more. Most people needing to do this right now for arbitrary HTML would probably be better served by having their webapp make a request to a server to run wkhtmltoimage and return the image.
The project isn't actively maintained and I never managed to compile it myself, so I wouldn't be able to effectively maintain or extend or fix issues in it. It doesn't have any hooks to call code when it's done rendering something, so I had to experiment and finally I noticed it would call a specific webgl method when it was done, so I would monkey-patch that webgl method to call my code afterward.
Then there's the issue that it's a 5mb download (gzipped) to the user's browser. It was only needed for a little-used feature, so I made the file not be requested until the feature is triggered, and then the download progress is shown on a modal. (And then the browser keeps the script cached after loading it once, so future uses of the feature are quicker.)
In the end, it works well for my use case here. Some parts of my use case that helped it work was the fact that immediate rendering wasn't necessary (it was fine to make the user wait for it to load), and the fact that it only had to work on HTML that the web app itself generated. webkit.js doesn't handle things like images or remote resources currently, so it wouldn't work well for arbitrary user-provided pages.
While this is an interesting approach I would not recommend this for anything other than desktop websites, where bandwidth and performance are less of an issue, simply because you are loading every single "Thumbnail" as a full webpage inside those iframes. Downloading all the associated scripts, stylesheets and other resources.
So basically you think the cost of generating a thumbnail of a website (likely less than 1/100 of a cent) is too expensive, so you make the client do it and destroy usability in the process by making the page slow to a crawl. Remember, usability has a value, since you wouldn't make the website in the first place if people couldn't use it.
17 comments
[ 5.5 ms ] story [ 24.6 ms ] threadWe solve this by taking server side screen shots (currently using slimerjs). We used HTML2Canvas in the past, but it wasn't reliable enough.
It would be great if there was a built-in browser method though, to just get a bitmap of the screen in Javascript. I've heard about security considerations in the past — a prompt for access would not be a problem in our case.
Exposing it using an API would be amazing. But there are most definitely security considerations that would have to be worked around.
Chrome has this (not sure about FF/IE) for extensions. Just add the 'tabs'/'desktopCapture' permission and call the appropriate API[0][1].
[0] - https://developer.chrome.com/extensions/tabs#method-captureV...
[1] - https://developer.chrome.com/extensions/desktopCapture
Agreed. And suppose the "thumbnailed" website had a thumbnail of the parent linking site...
I've used webkit.js (https://github.com/trevorlinton/webkit.js) to implement a client-side save-chart-to-image feature in an web app. Not really sure if I'd currently recommend it, but the strategy has promise if developed on more. Most people needing to do this right now for arbitrary HTML would probably be better served by having their webapp make a request to a server to run wkhtmltoimage and return the image.
The project isn't actively maintained and I never managed to compile it myself, so I wouldn't be able to effectively maintain or extend or fix issues in it. It doesn't have any hooks to call code when it's done rendering something, so I had to experiment and finally I noticed it would call a specific webgl method when it was done, so I would monkey-patch that webgl method to call my code afterward.
Then there's the issue that it's a 5mb download (gzipped) to the user's browser. It was only needed for a little-used feature, so I made the file not be requested until the feature is triggered, and then the download progress is shown on a modal. (And then the browser keeps the script cached after loading it once, so future uses of the feature are quicker.)
In the end, it works well for my use case here. Some parts of my use case that helped it work was the fact that immediate rendering wasn't necessary (it was fine to make the user wait for it to load), and the fact that it only had to work on HTML that the web app itself generated. webkit.js doesn't handle things like images or remote resources currently, so it wouldn't work well for arbitrary user-provided pages.
The iframe will reset the source of the top level page and will cripple your app.
If you control the domains you are embedding this won't be a problem, but if you don't - then it's a risk to be aware of.
Granted, this won't prevent other framebusting techniques such as checking the parent before rendering.
The resource overhead of just one "thumbnail" will be insane, and your mobile users will hate you.
This "thumbnail" can then do anything a website can, like alert dialogs and location requests.
http://chromeutils.appspot.com/t/?url={{::site.url}}
http://chromeutils.appspot.com/t/?url=news.ycombinator.com