Headless mode in Firefox
developer.mozilla.org
developer.mozilla.org
``` browsers: ['FirefoxHeadless'], customLaunchers: { FirefoxHeadless: { base: 'Firefox', flags: [ '-headless', ], }, }, ```
Note you need to be running the beta version of firefox, I needed to download it from here https://www.mozilla.org/en-US/firefox/channel/desktop/
Does not play well with React Fiber either, in my experience. Aaaand isn't the brain behind PhantomJS stepping down or something? To any potential users: just go with Chrome
That's what we currently do, karma and browser testing are useful but sometimes you can get away with not using them.
One thing we are trying is using JSDom to run browser based tests in node
Also note that that's only the case on Windows and OS X (it's already released for Linux), and only as long as Firefox 56 hasn't been released yet :)
What does everyone else use for browser tests?
You do "pure" unit tests, which test most of the logic, computations and intention in nodejs, then rely on (usually just a few) E2E tests in selenium or whatever to make sure stuff actually work in the browser.
For example, in a standard React/Redux app with low amounts of legacy code, you can test almost all of the app's constructs in node and be very confident that everything works.
There's still a few places where Karma + Browser shine. Namely when something requires a unit test-style environment but is integration heavy. Think libraries abstracting browser details such as a rich text editor or a library like jQuery.
Where does one find a customer launcher?
Thank you for your helpfulness, regardless.
Years ago I could always find a way to make Perl do whatever I wanted. It was usually "wrong" to fire up an entire interpreter compared to using faster, less flexible tools but it got the job done. Now I imagine people thinking, "the browser will do this", especially if they can grab screenshots or other local data files.
Which is not to say there is not common effort between the projects you mention now.
chromium-browser --headless --disable-gpu --print-to-pdf=output_file_name.pdf file:///path/to/your/html
It works very well, but there are some gotchas with regard to the Chrome Remoting Interface.
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 before capturing, ie: 10 seconds?
In an ideal world, a true "finished loading" event would trigger only after all DOMContentLoaded and onload handlers are executed, only once any AJAX requests launched by such handlers are completed (including requests fired off in their handlers, recursively). Of course, websockets and long polling ajax would still interfere with detecting a true "finished" event, but it'd be better than setting an artificially large delay of 10+ seconds.
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.)
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.
I used this approach for a project at a previous company and not only did it keep the potentially unsafe external code execution isolated from the rest of the stack, but it also proved to be fantastically scalable because of the ability to have AWS Lambda running many headless browsers in parallel compared to trying to scale something like this out on your own hardware.
It also supports page-oriented CSS declarations and variables, like headers, footers, page numbers, etc.
Browsers are catching up on paged media options, but they're not all the way there yet. The rest of the stuff Prince does is not (and arguably shouldn't be) in the scope of headless Chrome.
There was a brief moment where headless Chrome supported flexbox in print before Prince did, but that was fixed a month or so ago in Prince dev and should land in production soon if it hasn't already.
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.
Stuff looks like it was created with QuarkXPress or Adobe InDesign.
To get better control of the print job, do you ever use Adobe InDesign?
Edit: so people know what versions are pegged.
Can't wait for a cross-platform headless Edge :-)
My general rule of thumb is to try having as few end-to-end tests as possible. It's fine for an e2e test to cover multiple aspects of your application. Trying to write e2e tests as if they were unit tests just leads to sadness and infinite CI builds.
I don't think there's any value to running all your tests on the browser. It's much faster and simpler to run the bulk of your tests on node, with a fake DOM environment.
If you're interacting directly with the DOM, you might want to consider breaking that off as a separate lib. From the lib's repo you can have all of its tests run on a real browser.
Testing everything in a browser/e2e provides a rather poor cost/benefit ratio, especially as the project grows and more features and tests are added, so it should be reserved for cases where it is really important.
I like having e2e tests that cover the very core functionality and involve multiple parts of the stack. For example, if you have your rather typical app with a login modal, it's probably good to have a test that clicks on the button, makes sure that the modal is visible, and the user is redirected to the expected page after logging in. But testing if error message is displayed if email address is invalid? That's too much.
(And yeah, cross-platform Edge would be nice for being able to test in CI without needing a third party.)
We think we'll begin work on Firefox headless soon. PRs welcome :)
NeWS, Display PostScript, Quartz all come to mind. I know you can save webpages as PDF documents, but I am thinking of something that is like PDF but closer to HTML-just more closely coupled to what is being displayed, and not whatever arbitrary style or JavaScript abuse the developer decided on.
Even just outputing some neat, canonical HTML based on the state of the page once everything is loaded would be helpful, so that the bitmap could later be combined in some kind of new document format.
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.
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.
You spin up a copy of your server, point the headless browser at it, run some JavaScript to simulate some user interactions, and verify the page contains the right strings / screenshot doesn't deviate too much from a golden image.
I guess the ELI5 way of saying that would be: "Making sure your website still works."
People also headless browsers for content generation inside larger systems. (I saw one team make videos by creating CSS animations, and then capturing screenshots from the headless browser at 30 fps.)
Thanks!
Putting the website through user actions in a firefox browser and recording/capturing/documenting the results headlessly. Headless version allows you to go through hundreds of results in the background.
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.
Crawling the Web. Although you might think that you can crawl a web site by poking through the HTML looking for <a> tags and opening the URLs they contain; that stopped working well a long time ago. Modern sites are essentially complex GUI applications that run inside...a browser. You need either a browser, or some browser-equivalent thing therefore in order to run them and properly crawl them.
https://bugs.chromium.org/p/chromium/issues/detail?id=696481
Soon.
In the interim I've been using standard C# web requests and using the cookies from the ChromeDriver. Doesn't work for downloads where it is not a direct link unfortunately.
Headless Chrome/Firefox render the website into a framebuffer in memory (instead of on the screen), but websites still look the same. You can extract an image file from this framebuffer and it will look as if the browser had been running in normal GUI mode.
Lynx on the other hand renders onto a text terminal, which is a completely different output device compared to a pixel-based framebuffer.
"xvfb-run firefox" and "firefox -headless" should be functionally equivalent. But I would still be interested in performance comparison with numbers.
I meant equivalent from the point of view of the user who wants to run tests, not on the way they work internally.
We are sticking with phantomjs for now because it is significantly faster than chrome for our tests.
I'm guessing you can lookup the webdriver spec to see what you can do...
wbaas.io "web browser as a service"
Support like say the 5 major browsers (Firefox, Chrome, Safari, ...), provide an API and charge like ~xx euro/month.
The biggest challenge is probably to make it secure as one builds in essence a DOS proxy?
We secure all VMs with a firewall, every test runs on a new VM which gets destroyed after the test.
https://bugzilla.mozilla.org/show_bug.cgi?id=1338004
So not in reaction to Chrome.
In fact, the first attempt for this was almost a decade ago (https://bugzilla.mozilla.org/show_bug.cgi?id=446591)
It's a decade to decide this is worth doing, which is reasonable given that there's also a "good enough" solution out there; Selenium.
This seems way too fast to be a response to chrome
I remember using this with xvfb to achieve headless Firefox. The rendered text could then be accessed via localhost with a text-only browser or tcp client e.g. netcat.
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.
Firefox does some weird stuff with multiprocessing, where if you run the firefox command twice you only get one process. I don't know how that would effect things, but I imagine just setting the env variable and running as a different firefox profile would do it.
There's always firejail/firewarden, if you need a quick and easy sandbox for a program you already have installed, and that will solve that problem, if it is a problem.
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.
network.IDN_show_punycode = true
https://wiki.mozilla.org/IDN_Display_Algorithm
Much better than showing punycode all the time.
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)
[0] https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm
[1] https://www.chromium.org/developers/design-documents/idn-in-...
In the end, you would just highlight nearly everything. A more useful approach would be to highlight when you switch script inside a domain name. That seems to be what firefox does for non-whitelisted domains (with some more rules to allow eg www.stマイクロ.jp (ST Microelectronics in japanese))
From: "https://mail.google.com"
If they looked the same.
Because the #1 use case for this isn’t emoji, but sites such as bücher.de (I originally had a link here to the site, but HN punycodes that: http://xn--bcher-kva.de/ ) (which nowadays had to redirect, because the URL displayed in punycode made people believe it was a phishing attempt)
A full source reputation, authentication, and integrity capability strikes me as far more useful.
> where the UI appears when you need it, intuitively, even when NOT in full screen
or how it relates to a headless browser.
In i3, if you run firefox normally it opens up in a pane, if you choose full screen (f11) inside firefox, it fills up the entire pane. In the other panes you can still keep your other windows, such as emacs, file browser, terminal etc.
"Headless" means without output. It is often used to describe servers without any attached monitors (the monitor would be the head that it is missing), but can similarly be used to describe browsers that do not even create a window on your desktop. It simply runs as a service that can be scripted.
What you are looking for, I would rather call "chromeless". The browser is there, but it has no visible UI-components outside of the webpage.
Why "chromless" and not just "Full screen"? The latter is what that mode has been known by for decades? Or is it a subtle distinction that "Full screen" mode can show the location bar by moving the mouse to that edge of the screen (at least in Firefox 55), while "chromless" never lets you see the location bar?
A chromeless windowed browser would look something like QuickTime in macOS, if that helps you; the window consists entirely of the playing video until you mouse over it.
Anyway, IE11 on Windows 8 (tablet mode) had that, and it was amazing (assuming you used the touch screen, that is - the UX wasn't so fantastic with a mouse).
It's the only thing from Windows 8 I miss in Windows 10.
JavaScript Fullscreen API: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_...
Cross-browser polyfill: https://github.com/sindresorhus/screenfull.js
Your job is to make things usable & functional, not pretty.
https://www.reddit.com/r/dredmorbius/comments/6bgowu/what_if...