Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

headless version #769

Open
megablue opened this issue Jun 7, 2013 · 115 comments
Open

headless version #769

megablue opened this issue Jun 7, 2013 · 115 comments

Comments

@megablue
Copy link

megablue commented Jun 7, 2013

It would be great that if node-webkit are made into headless version...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@Mithgol
Copy link
Contributor

Mithgol commented Jun 7, 2013

You mean, like, the same Node.js engine and API, but without any browser-alike HTML+CSS interfaces?

But that's what original Node.js is. Maybe you should just get it instead of node-webkit then.

@tommoor
Copy link

tommoor commented Jun 10, 2013

Sounds like you're looking for www.phantomjs.org

@dhendo
Copy link

dhendo commented Jul 8, 2013

@ronward
Copy link

ronward commented Dec 2, 2013

I would very much like to see a headless option for node-webkit.
And yes I know that is like phantomjs, but phantomjs does not have the nodejs integration that node-webkit has.
Also it can them mean just the one code base and not having to testing to see which environment you are running under etc.
A must have feature! IMHO

@szwacz
Copy link

szwacz commented Dec 3, 2013

I didn't get the point of this feature. What exactly you are expecting out of headlessness? Why today node-webkit with hidden main window is not the solution?

@ronward
Copy link

ronward commented Dec 3, 2013

The reason that node-webkit with just the main window hidden is not a solution is because it still expects a display (XWindow/XOrg). e.g. you cannot run it on a server because there is no display. (this is on Linux)
When I try this I get the message: Gtk-WARNING **:cannot open display
[25522:0100/000000:ERROR:zygote_linux.cc(498)] write: Broken pipe

@katanacrimson
Copy link

@ronward ...then just run node?

@ronward
Copy link

ronward commented Dec 3, 2013

But node does not have the browser context!
What I want is more like PhantomJS (yes I know, then just use PhantomJS), but it would be very nice to have the combination of node and the browser context (e.g. node-webkit) in one. (and there may be other solution e.g. https://github.com/deanmao/node-chimera/ as mentioned above, but this would mean rewriting code or having two code bases)

@rogerwang
Copy link
Member

This is on my plan. Before that you can use xvfb, xvnc or other X server which don't need a physical display on your server.

@ronward
Copy link

ronward commented Dec 3, 2013

Thanks, that a very good idea that I had completely forgotten about. (used xvfb to run OpenOffice ages ago when there headless option still had some bugs)
By the way I just love the node-webkit idea/system/setup! Thanks

@kaizhu256
Copy link

+1
valid use cases for a headless node-webkit are:

  1. provide automated browser testing and code coverage on a build server
  2. running a web-scraper on a server

@edwardchanjw
Copy link

headless should help develop background apps?
or
We can set show to false in the manifest of your application with similar purpose?

@tommoor
Copy link

tommoor commented Jan 22, 2014

To me this dilutes the projects aims. Phantomjs does absolutely fine for 99% of purposes.

@Mithgol
Copy link
Contributor

Mithgol commented Feb 13, 2014

I was the first here to point to another project that looks like a headless node-webkit, but today I myself encountered a perfectly valid case for using a headless node-webkit — a case where nothing else would suffice.

That's Travis CI testing of a Node.js addon-containing module. There's no other way to test if a module runs on node-webkit; the module has to be built by nw-gyp and run on node-webkit to see what happens.

And, almost like @ronward said above, I saw precisely the following:

node-pre-gyp ERR! stack Error: Command failed:
node-pre-gyp ERR! stack (nw:2106): Gtk-WARNING **: cannot open display:
node-pre-gyp ERR! stack [2109:0100/000000:ERROR:zygote_linux.cc(478)] write: Broken pipe

You also may look into the my Travis CI log (lines 1271—1273) for an example.

@Mithgol
Copy link
Contributor

Mithgol commented Feb 13, 2014

@rogerwang

Before that you can use xvfb, xvnc or other X server which don't need a physical display on your server.

Sounds like a good plan.

Travis CI even provides a script for starting xvfb.

Now how do I run node-webkit on xvfb?

(Unless it already does that automagically based on $DISPLAY, which I am going to check soon.)

@Mithgol
Copy link
Contributor

Mithgol commented Feb 13, 2014

Got Package appears valid on this log, line 1272. It seems that xvfb is enough for a headless node-webkit on a Travis CI server.

@Mithgol
Copy link
Contributor

Mithgol commented Feb 13, 2014

Running 32bit node-webkit on 64bit Travis CI Linux is also possible (though a bit tricky), see #1566 for details.

@FWeinb
Copy link
Contributor

FWeinb commented Feb 15, 2014

@Mithgol I get a:

Xlib:  extension "RANDR" missing on display ":99".
[1183:0215/113833:ERROR:breakpad_linux.cc(1225)] crash dump file written to /tmp/chromium-renderer-minidump-5d9a40a22d7d15b8.dmp

when running v0.9.1 - Feb 11, 2014(64bit) on a digitalocean 5$ instance. I started xvfb like this:

/usr/bin/Xvfb +extension RANDR :99 -ac -screen 0 1024x768x8 &

Any idea?

@Mithgol
Copy link
Contributor

Mithgol commented Feb 15, 2014

No idea, sorry. My experience does not tell me anything about that. Two days ago I've run xvfb for the first time in my life. I suppose there's some difference between digitalocean and Travis, because in Travis docs they write something very similar to your attempt (except that +extension RANDR thing and bit depth).

@FWeinb
Copy link
Contributor

FWeinb commented Feb 15, 2014

Thanks for your quick answer. I could get it to work. There where some font's missing

sudo apt-get install -y xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic
sudo apt-get install -y x-ttcidfont-conf cabextract ttf-mscorefonts-installer # accept the EULA
sudo dpkg-reconfigure --default-priority x-ttcidfont-conf

The +extension RANDR isn't needed.

@cretz
Copy link

cretz commented Feb 16, 2014

For those looking for another usecase here, a headless WebRTC peer would be very nice. From what I can tell, PhantomJS does not support this Chromum feature and https://github.com/js-platform/node-webrtc seems not to be up to par yet for cross-OS and easy installation for users. I very much look forward to headless node-webkit.

@CooCooCaCha
Copy link

Another future use-case would be for PDF rendering. PhantomJS is nice but it is dependent on QTWebkit for updates. I like the idea of doing PDF rendering from a library that runs on chromium and node than one that runs on QTWebkit.

@Mithgol
Copy link
Contributor

Mithgol commented Mar 14, 2014

A brief follow-up on the RANDR problem. Todd Wolfson says that it's fine to ignore the Xlib error about RANDR. I guess we all have to expect (from now on) that stderr of node-webkit can be non-empty even if everything else is fine (including the application's exit code).

@Mithgol
Copy link
Contributor

Mithgol commented Mar 14, 2014

Also, I tried +extension RANDR on Travis CI's version of Xvfb today.

It does not seem to prevent the same node-webkit's RANDR-related Xlib error.

Useless.

@Starcounter-Jack
Copy link

Reasons that Node-Webkit would be the better headless browser:

  1. PhantomJs is based on Webkit whereas Node-webkit is based on Blink. Will Apple
    maintain Webkit on non Apple platforms? Opera, Qt and others are moving away
    and Safari is discontinued on non Apple platforms.
  2. V8 performance is much better than JavaScriptCore in PhantomJs
  3. One of the uses of headless browsers is crawlable Ajax. PhantomJs does not support web components or Polymer making PhantomJs a non-option for this use case.

@jcrubino
Copy link

With WebRTC entering the mainstream a headless chromium api would help create services based on WebRTC. Just saying there is a need not what the best solution is.

@Rameshv
Copy link

Rameshv commented Apr 2, 2014

+1

@tbranyen
Copy link

"To me this dilutes the projects aims. Phantomjs does absolutely fine for 99% of purposes."

This is not a valid counter argument. In what way does PhantomJS share a V8 context with Node as the project aim of Node-webkit does?

@polpo
Copy link

polpo commented Nov 11, 2016

My main need for headless is the ability to run my NW.js app (with nwjc-compiled modules) on the command line in Linux without an X11 server running. So far my workaround has been to start an Xvfb server but I'd much prefer to not rely on that.

@drom
Copy link

drom commented Nov 11, 2016

@rogerwang I need NWJS application that combines Node and Browser DOM rendering and can run in pure CLI mode when needed. Agree with @polpo

@damoebius
Copy link

@rogerwang my NWJS application use the Node Api AND the DOM, Canvas, WebGL, WebWorker, to compute images at server side.
It could be run in pure CLI on a headless server

@tentone
Copy link

tentone commented Nov 11, 2016

I can see myself in the future using it for a webserver that processes image with webgl :)

Do code starts from an HTML file samr way as with the not headless one?

@tekrat
Copy link

tekrat commented Nov 11, 2016

After started headless we could we have a way for additional interactions. The 'console' could be extended to include something like the interactive function below. That would left it run as a full shell or console application and just command line switch. This maybe more useful if doing an SSH into a server. Some of these are things I look for from my BBS days :).

All of these are variation on the console.log() function. The main difference is that they extend the 'console' object for input and output in an interactive console/shell application:

  • console.read() - Read a single character from input, return the character value
  • console.readLine() - Read a line of text until you press Enter, return the character value
  • console.write(s) - Write some character would not end with CRLF of LF
  • console.writeLine(s) - Write some character would end with CRLF of LF
  • console.color(f,b) - Send an escape code to set a foreground (f) and an optional background color(b)
  • console.blink(b) - Turn blinking text on or off (b = 0 or 1, or true and false)

@Mithgol
Copy link
Contributor

Mithgol commented Nov 11, 2016

I feel that a headless NW.js build flavor would be quite useful when it becomes necessary to test the behaviour of custom builds (builds made by nw-gyp and targeting NW.js specifically) of binary addons that reside in Node.js modules (such as sqlite3 or serialport for example).

Such modules cannot be tested merely on a headless Chromium (because the modules need Node.js API) or in NW-less Node.js (because the addons are rebuilt to have NW.js ABI).

Additionally, if the tests are running on Travis CI, then it's quite beneficial to migrate from their old infrastructure to their new container-based infrastructure (because then builds start much faster and they also run faster), but after such migration there's no sudo and thus (obviously) no sudo xvfb-run tricks (mentioned above by @chriddyp) are possible to run an unmodified NW.js headlessly.

(I must admit that Travis CI instances have xvfb installed and thus it's still possible to achieve something but I'd still be more comfortable with an NW.js build which is already headless.)

@jonnermut
Copy link

@rogerwang the obvious differentiator is also the killer feature of nw.js itself - running nodejs and a full DOM in the same JS context. Having a headless mode opens up very useful server side rendering possibilities.

@kardianos
Copy link

(I apologize for the drive by comment.)

I'm looking for a replacement for wkhtmltopdf on windows server (no xvfb) for generating reports; the two major issues with wkhtmltopdf is it still uses the OS DPI settings (reports vary from dev to server) and isn't staying up to date with recent versions of webkit so old bugs are hurting more and more.

I'd like to note two interesting developments:

  1. Google chrome is growing a --headless flag in the standard build,
  2. The addition in NW.js of the win.print method.

I would also like to note I've seen phantomjs and I cannot use it for my purpose (generating PDF reports). Right now depending on wkhtmltopdf which depends on QT webkit isn't a sustainable option. It would be great to have an alternative.

@julkue
Copy link
Contributor

julkue commented Dec 24, 2016

Why can't you use Phantomjs?

@kardianos
Copy link

phantomjs_long_page.pdf
wkhtmltopdf_long_page.pdf

phantomjs doesn't support page-breaks and doesn't go through a print pipeline in general. See attached files for differences.

@julkue
Copy link
Contributor

julkue commented Dec 24, 2016

Can you please share your Phantomjs settings?

@kardianos
Copy link

@julmot You are correct, I may be able to use phantomjs using something like https://github.com/ariya/phantomjs/blob/master/examples/rasterize.js . I'm sorry for the distraction.

@damoebius
Copy link

PhantomJS maintainer stepping down after Google's headless Chromium announcement

@drom
Copy link

drom commented Apr 13, 2017

Announcement itself: https://www.chromestatus.com/features/5678767817097216
Excited to see this feature in NWJS

@rogerwang
Copy link
Member

rogerwang commented Apr 14, 2017

Thanks. I've been watching the headless development in upstream closely. NW has been delivering whatever Chromium browser supports. So I'll see and make sure the --headless command line switch works in the first step.

Please note that in upstream, there are 2 browsers in the Chromium binary (headless, and the normal one which we've been using). When --headless is specified, Chromium will switch to and launch the headless browser instead of the normal one. The difference between the 2 browsers can be large for some users, in the same way as content shell vs the browser. It's not like that the normal browser has supported a headless mode.

So when NW supports the upstream switch in the first step, it will deliver the same thing as the upstream headless browser, not like NW apps will run in headless mode. In the 2nd step, the Node integration will be added. The NW application model and the NW API will be the last as the upstream headless browser doesn't support any extension mechanism.

@rogerwang
Copy link
Member

Update: the upcoming 0.23.0 beta will support headless usage as in upstream: https://developers.google.com/web/updates/2017/04/headless-chrome
https://dl.nwjs.io/live-build/04-29-2017/nw23-3bd4af6-4d7f95f-5e6428a-f2085b9/v0.23.0-beta1/

@VasiliyIsaichkin
Copy link

I still could not run code in headless mode (ubuntu 16.04/terminal), nw start and terminate, but code not start. I try to use script in html and set js file directly to main section in manifest:
Example:

require('fs').writeFileSync('test.test','TEST');

but file not created, express server also not started

@mgttt
Copy link

mgttt commented May 28, 2017

@rogerwang dear roger, i'd like to suggest that in the "headless" mode, some mthod should be added so that the caller can demand the instance back to GUI-mode (so that the user can switch to manually mode). Yup, let compare the headless as "Auto" mode and GUI as "Manual" mode when we "drive" the vehicle

@ghost
Copy link

ghost commented Jul 13, 2017

I'd love to see the ability to spawn a headless window using nw.Window.open - similar to how you have the "new-instance" flag currently.

@dmouton
Copy link

dmouton commented Sep 29, 2017

Hi,
Is it working ?
I get the latest nwjs version 0.25.4
I use headless args like that :
{ "name": "#name#", "version": "5.1.0", "main": "index.html", "chromium-args" : "--headless --disable-gpu --no-sandbox --disable-setuid-sandbox", "window": { "show": false } }

But i get a Gtk-WARNING : cannot open display

What's wrong ?

Thank you

@alFReD-NSH
Copy link

I had success running nwjs v0.18.6 with Xvfb thanks to hauptmedia/nwjs docker image, but I couldn't make it work with the latest version with Xvfb. If anyone made it work, it'd be nice if they publish their dockerfile.

@IssueHuntBot
Copy link

@BoostIO funded this issue with $10. Visit this issue on Issuehunt

@IssueHuntBot
Copy link

@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt

@drom
Copy link

drom commented Feb 28, 2019

Any update on the issue?

@IssueHuntBot
Copy link

@0maxxam0 has funded $2.00 to this issue.


@gahubaul
Copy link

Any news here ? No update since times

@denim2x
Copy link

denim2x commented Jan 27, 2021

I'm looking into it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests