Live data from Hacker News

Headless mode in Firefox

developer.mozilla.org

181–190 of 191 posts

Re: Headless mode in Firefox

#181

Earlier quoted context omitted.

It would be cool if browsers could highlight URLs that contain the kind of characters which are commonly used to spoof, though I suppose it would lead people to a false sense of security.

Just set your browser to always show punycode. On Firefox, network.IDN_show_punycode = true URLs are no place for unicode characters to hide in. An xn-- prefix is all the warning you need.

So sites such as bücher.de (I originally had a link here to the site, but HN punycodes that: http://xn--bcher-kva.de/ ) shouldn’t exist?

That’s a very america-centric world, it’s like enforcing only US-ASCII on all websites. Most of the world doesn’t speak English, and browsers showing domains punycoded leads to mistrust, especially if it’s a legitimate retailer (the one mentioned above actually added a redirect to a romanized version of the URL due to that)

Re: Headless mode in Firefox

#182
post #170

Earlier quoted context omitted.

That's a neat approach, I'm not on anything like that scale though, looking for something to get rid of JasperReports.

Did you find any library that implements this? I mean, it should not be hard to implement, just slap together some templating language like thymeleaf or velocity and shell it to the headless browser. But still, it would be nice to have all this already implemented.

Last time I had to generate PDF's from scratch rather than inheriting a mess I built a custom heavily modified version of bootstrap (really ripped it apart) just for print use and fed it to wkhtmltopdf via snappy, it worked great and was very fast to develop since I could output to the browser as HTML to debug.

Re: Headless mode in Firefox

#183

The article mentions screenshots. I am interested in running the browser as a rendering tool, but ouputing not just a bitmap, but something closer to PDF. The goal here would be to crawl a bunch of pages and spin up the CPU to run all the needed JavaScript to render things, but to obtain an identical version of the page that runs about as fast viewing a screenshot, but also includes text. An offline "web OCR", if you…

What you want is SVG. You want an SVG output of the actual, full, page. With text embedded in SVG properly, of course.

That is actually exactly what I want (why didn't I think of it...)! Thank you.

In fact, wkhtmltoimage supports svg and does a great job of rendering, say, GitHub or techmeme. It falls over on formatting mathoverflow.net, but I think the same technique could be changed a bit to more closely resemble what actually gets layed out on the page in a running browser instance.

Re: Headless mode in Firefox

#184

Perhaps I'm spoiled, but I'm wondering why this wasn't a thing many years ago. Am I wrong in saying this was brought about in reaction to Chrome adding the same feature, or has this been there for a while? Clearly people wanted this for ages, hence the work on things like PhantomJS. But it seems like it was only added once they realized they needed to play catch-up with Chrome.

Hi, I'm the Product Manager for Headless Firefox at Mozilla.

No, this wasn't a reaction to Chrome. We decided to implement headless mode last fall after research last summer indicated that it would increase website testing in Firefox and thus improve web compatibility.

Of course, I was aware at the time of Chrome's own efforts to implement a headless mode, and I've continued to pay close attention to their work.

I've also made similar decisions to Chrome at times (f.e. to use the same --headless command-line argument to enable the mode), while making different decisions at other times (like deciding to prioritize support for the WebDriver API, whereas Chrome has focused on support for the Chrome DevTools Protocol).

But my focus has been primarily the direct benefits to web developers of being able to run tests against headless Firefox; and the indirect benefits to Firefox web compatibility of more web developers testing on Firefox.

Re: Headless mode in Firefox

#185

Does it require X to be installed? If so, it's not headless.

It does require X to be installed, although it doesn't actually use X, and the X implementation can just be Xvfb.

Unfortunately, fixing that is hard. I think Chrome has the same limitation. For Firefox, the issue is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1372998.

Re: Headless mode in Firefox

#186
post #166
post #145

Earlier quoted context omitted.

PrinceXML is in a league of it's own. Very, very light weight. Very fast and it has outstanding output. The price tag is steep for sure, but if your business relies on PDF output then nothing comes close.

Do you use it in the context of technical documentation? Does it make using Docbook a bearable experience?

It has unmatched print CSS support, so it'll take anything you throw at it.

Also it blisteringly fast. You'll process 10 documents before headless Chrome has even finished starting up.

There's a free trial which prints a watermark so you can give it a spin. very easy to get up and running, even has a GUI so that you can throw some test docs at it without any effort at all.

Re: Headless mode in Firefox

#187
post #17

Earlier quoted context omitted.

You can generate pdfs with headless Chromium/Chrome pretty easily[1]. chromium-browser --headless --disable-gpu --print-to-pdf=output_file_name.pdf file:///path/to/your/html [1] https://developers.google.com/web/updates/2017/04/headless-c...

Any idea when exactly the PDF capture is performed? So many pages now render a minimal initial load, while the actual content is greatly delayed (usually Capturing the PDF at even the onload event (let alone the useless DOMContentLoaded event) is going to capture an incomplete picture in a huge number of situations. Frankly, a PDF capture at onload event is going to be utterly unusable. Is there a way to set a delay…

I don't think this feature is "utterly unusable". You can run your JS, wait for whatever events you want, and then pipe the resulting HTML to a --print-to-pdf command.

Re: Headless mode in Firefox

#188
post #101

Can someone do an ELI5 on why headless browsers are useful? I've use them before to make screenshots of webpages, and I have noticed that many NPM packages come (or came) with PhantomJS as a dependency, but I have no idea why one would need that.

Where I work ( https://phantombuster.com ) we use them for scraping the web. They're a hassle-free way of getting the data. No need to worry about CORS, sessions, cookies, CSRF and other modern web stuff. Just simulate a human and you’re in.

Yeah, I used to work for a company doing similar things. Was more expensive that way, but there were tons of sites you could only get the data being in a proper browser.

Re: Headless mode in Firefox

#189
post #17

Earlier quoted context omitted.

You can generate pdfs with headless Chromium/Chrome pretty easily[1]. chromium-browser --headless --disable-gpu --print-to-pdf=output_file_name.pdf file:///path/to/your/html [1] https://developers.google.com/web/updates/2017/04/headless-c...

Any idea when exactly the PDF capture is performed? So many pages now render a minimal initial load, while the actual content is greatly delayed (usually Capturing the PDF at even the onload event (let alone the useless DOMContentLoaded event) is going to capture an incomplete picture in a huge number of situations. Frankly, a PDF capture at onload event is going to be utterly unusable. Is there a way to set a delay…

Amusingly, I had this same problem back in ~1999 when trying to automatically screen capture webpages with Netscape on X.

Except then it was just a case of "wait 30 seconds and pray" because there was none of this fanciness.

(bloody kids, get off my lawn, banging two rocks together, etc.)

Re: Headless mode in Firefox

#190
post #34

Earlier quoted context omitted.

Remember that if you pass through any data from an outside source, you're running their code on your browser when you thought you were just printing a document. The security issues don't apply in all circumstances, of course, but if you feel like taking a shortcut to PDF generation and printing through a headless browser, you need to keep them in mind.

Rendering a PDF you got some other way is also "Running their code", just in a different sandbox :-)

I don't think you're thinking of the same case: this is "open a browser, and output a PDF"; not "read a PDF."
Post reply on HN