71–80 of 88 posts
"headless" Poke me when there are no X11/Qt/GTK/whatever dependencies at all - that is headless. https://packages.debian.org/stretch/firefox-esr
If your running this on a server sure great. On desktop that is next to pointless due to the need for those dependencies for everything besides cure apps.
Which is certainly the obvious primary use case for headless browsers.
It's not very clear how to actually use this in a test environment like Selenium etc. At least with headless Chrome there are libraries now to drive it via the remote debug protocol like https://github.com/LucianoGanga/simple-headless-chrome This feels a little nicer than Selenium as it's one less layer of abstraction. EDIT: guess from other comments WebDriver is the right method to access.
FWIW, from the Chome side, we think there's more power via the protocol rather than WebDriver.
BTW, I'm in Mozilla San Francisco office, so I'd be happy to chat about the headless cross browser future if anyone from the headless Chrome team is around.
It's not very clear how to actually use this in a test environment like Selenium etc. At least with headless Chrome there are libraries now to drive it via the remote debug protocol like https://github.com/LucianoGanga/simple-headless-chrome This feels a little nicer than Selenium as it's one less layer of abstraction. EDIT: guess from other comments WebDriver is the right method to access.
FWIW, from the Chome side, we think there's more power via the protocol rather than WebDriver.
* Doesn't generalise to driving other browsers. Using a standardised API gives you the possibility to run your automation against any top tier browser. If you are testing a website this ought to be a top consideration.
* Uncertain compatibilty story. I assume that the devtools protocol can change at the whim of the Chrome team. Using something standardised means that your tests and client are more likely to continue working.
* More limited selection of clients. WebDriver in particular has a large number of production-grade clients that are actively maintained.
I'm not claiming that WebDriver is perfect; certainly if I designed it from scratch it would look very different. And yes, there is a period of churn as it moves toward being a standard. But I think the advantages of cross-browser support are a compelling reason for it to be the default tool for remote automation tasks that are within the scope of its featureset. By all means, if you have something that cannot be done with a standardized technology look at the proprietary solutions. But I don't think it should be your first pot of call.
What are the biggest challenges when implementing headless mode? I'm asking cause this feature took some time to be delivered both in Firefox and Chrome and I always assumed that it should be 'pretty' straightforward to implement. Is it that both engines were coupled with GUI libs?
One slight complication of headless has been wiring up the headless "widgets" (in Firefox, we refer to most of the platform specific code as widgets e.g. there's gtk widgets, cocoa widgets, windows widgets). Usually the widget type is defined statically at build time, but in the case of headless we wanted Firefox to either use the headless widgets or the platform specific widgets at runtime. Luckily, some of the work on multi-process Firefox work also added another type of widget and made it much easier to support multiple types of widgets.
Overall, the hardest part has been trying to replicate all the events that would normally be triggered by the platform gui code. I've also found that these events and order can vary per platform which makes it hard to do in a non-platform specific way. We're still working out some issues here.
But can you really run windows headless? I thought even the Server Core and IoT versions wanted some sort of GPU even just to display a blue/blank screen.
Earlier quoted context omitted.
FWIW, from the Chome side, we think there's more power via the protocol rather than WebDriver.
Well, yes, a low level protocol is going to have at least the same features as a higher level protocol implemented in terms of it. However I think you should mention the significant disadvantages of using a nonstandard API: * Doesn't generalise to driving other browsers. Using a standardised API gives you the possibility to run your automation against any top tier browser. If you are testing a website this ought to b…
Earlier quoted context omitted.
Upvote the bug! https://bugzilla.mozilla.org/show_bug.cgi?id=1372998 I doubt it'll happen anytime too soon, but Mozilla should see the community interest.
As minor counterpoint: Firefox is not strictly speaking developed "by Mozilla" but by the community. Mozilla's the curator, and has a fair bit of staff also working on it, but vast swathes of the codebase are community contributions. If you need FF to do a thing, and you think you have good enough ideas to contribute the solution there, then rather than upvoting a bug, or bumping it to ask what's happening, be the pe…