Headless version for testing #228
Comments
|
By using hidden browser window atom-shell can actually do what phantomjs does, the example in phantomjs's homepage could be translated to atom-shell: BrowserWindow = require('browser-window');
console.log('Loading a web page');
var page = new BrowserWindow({show: false});
var url = 'http://www.phantomjs.org/';
page.on('loading-state-changed', (event, isLoading) {
if (!isLoading)
//Page is loaded!
require('app').exit();
});
page.loadUrl(url);Of course we may need to add some more APIs for automation testing purpose. The only problem is instead of drawing into a virtual buffer, atom-shell actually draws the page into a real window, this would require a graphic environment, on Window and OS X it doesn't matter, however on Linux we have to use xvfb to provide a X server for atom-shell. This is by design in Chromium's content API, so we can not do anything to remove the dependency of graphic environment. |
|
I've had success with this lately (using Xvfb on an Ubuntu server). My use-case is capturing screenshots of templated pages. In fact, I've found that atom-shell through Xvfb on the server (an m3-large) has better performance than on my local Macbook pro. This led me to want to get atom-shell working through Xvfb in osx as well. Since osx ships with Xvfb, that part is easy. Can I get atom-shell to use an Xvfb display in osx? Using the standard |
|
Xvfb only works for applications that written for X11 environment, on OS X atom-shell uses Cocoa for display, which I believe can not work with Xvfb. |
|
Yeah kinda put that together. Probably not really a way to compile from source for X11 instead? |
|
@zcbenz it is currently not possible to create a |
|
@FWeinb can you open a separate specific ticket for the above? |
|
Created #475 |
|
I'm closing this because there is no way to draw a page without actually creating a native widget in Chromium, and I don't think they will ever allow it. For automatic tests, we do support Selenium. |
|
The CEF project has support for off-screen rendering, so you can draw the screen into a buffer instead of a window. Regarding X server for Linux, it seems there's a way to work without it by adding a target called Ozone (see discussion here). |
|
@etiktin Thanks for the information! I'm reopening this since there is an existing implementation on how to do it. |
|
We could really use support for this. We recently replaced Phantom with Electron in Nightmare and love it so far, but it doesn't work out of the box on Linux. Here's what we need to do right now to get it working: segment-boneyard/nightmare#224 (comment) |
|
I've been given the task to automate user behavior for one of our web applications that will be converted to a stand alone desktop Electron application. Before our company decided to make this move, we created page objects using the chrome web driver and interacted with the web application by invoking buttons/dropdowns/textboxes using the css selectors. Is there a way to do this with a web application that is wrapped with the Electron shell? The company plans on using the menu bar options to invoke certain functionality and I tried to get to the default menu bar options like File/Edit/Help using the JavaScript driver with no success. Are there any examples out there on how to do this? |
|
segment-boneyard/nightmare#224 (comment) it seems @matthewmueller's snippet works on Linux 👍 |
|
Has anyone gotten headless testing working on SuSE? Specifically SLES? |
|
@fritx The same used for SlimerJS, but that's NOT headless mode. |
|
@fritx that's what @zcbenz was saying, you have to have Xvfb running. Both CEF3 and Chromium Content Shell currently depend on Xlib. But with completion of Ozone: https://www.chromium.org/developers/design-documents/ozone |
|
Apparently, there is a master bug in Chromium itself: https://code.google.com/p/chromium/issues/detail?id=546953 |
|
Totally agreed with @keithkml - the solutions, although well-intentioned (thank you!), have been more along the lines of "alternatives" until an actual solution is provided. Along those lines, does someone here have sufficient expertise to answer the questions I posed in my previous comment? (And again, please excuse my ignorance! :)) |
|
I still don't get the point in responses. Could someone please give me a clarify that do we have NATIVE headless mode for electron app to run in the CI or not? |
|
@hitliubo Chrome has a Even if you can't use
|
|
@isiahmeadows Thanks for your information. Currently I have a web app running in browser and with chrome/firefox I could always add --headless for the headless testing. Recently we'd like to convert it to Electron app and I tried with --headless which does not work in my macOS. Now I know thee reason. Thanks! Actually I don't like the solution by xvfb as it's not native. However, given that we don't support native headless so I guess I need to give it a try. FYI - Now I'm using capybara for the testing. |
|
That would be great (y) |
This comment has been minimized.
This comment has been minimized.
|
I got redirected here from a post about rendering directly to a linux frame buffer, but this seems to be focused on headless testing. Has any progress been made rendering directly to a real frame buffer? |
|
@quinn I'm pretty certain you're going to need an X server, although you can run X11 (Xorg) on a frame-buffer if you like (see: https://www.x.org/releases/current/doc/man/man4/fbdev.4.xhtml). Edit: Actually after looking into this a little bit more, this can also be achieved by using ozone. ( https://github.com/jakwu/ozone-fb ) Adding ozone would also allow wayland support, another feature that electron is missing seeing majority of Linux distributions have since migrated to this. |
|
Based on the description of ozone-fb and @isiahmeadows comment, it seems GPU acceleration does not work if rendering to a frame buffer. |
|
@trusktr That's a 2 year old comment. I'd recommend not taking my comment as authoritative, as that could have changed (I haven't checked since then). |
|
I add headless lib to electron and call the HeadlessShellMain。 then it shows: Does that mean headless has been implemented? |
|
@bigben0123 thats interesting and very exciting! So you have compiled your own version of electron incorporating the headless shell from chromium? Have you tested in an environment without X on Linux to see if it works? When chromium is run in headless mode the render sub-processes are started with the passed through —headless flag (you can see this is you use ‘ps args’ from memory). Is this happening for you? (Strangely with electron currently if you try to start it with —headless the flag isn’t passed though to the render processes but is to the GPU process.) |
Yes, I run it on ubuntu which just start in user command mode. |
|
@bigben0123 do you have your changes somewhere? Even if this doesn’t make it into electron core for some reason I would love to be able to use it. |
|
This commit only merge chrome headless lib to electron and you can use it the same way as chrome does. As far as I'm concerned, chrome and headless has different content layer implementation. Like two browser shell, if you start headless it's nothing to do with chrome, only except you start by "chrome --headless". The one of headless goal is that ”Minimize the number of invasive or headless-specific changes (e.g., #ifdefs) to Chromium’s code base“. Therefore, it's difficult to implement that electron is headless to remove xvfb. We can just let electron support headless, but you cannot execute electron apps. We may use headless' implementation to replace electron's to get a new headless branch. remove the dependence from electron/BUILD.gn: replace with: |
|
It is ignored by Microsoft because of incompatibilities BUT you can use my fork: https://github.com/lnxx-kernel/electron_touch |
and others
@zcbenz how much work do you think it would be to create a headless version of atom-shell that could be used as a replacement for phantomjs?
phantomjs is lagging behind more and more from what actual web browsers do today and it would be great to have something more up to date to use for headless testing.
The text was updated successfully, but these errors were encountered: