-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Comments
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. |
Sounds like you're looking for www.phantomjs.org |
I would very much like to see a headless option for node-webkit. |
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? |
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) |
@ronward ...then just run node? |
But node does not have the browser context! |
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. |
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) |
+1
|
headless should help develop background apps? |
To me this dilutes the projects aims. Phantomjs does absolutely fine for 99% of purposes. |
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:
You also may look into the my Travis CI log (lines 1271—1273) for an example. |
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 |
Got |
Running 32bit node-webkit on 64bit Travis CI Linux is also possible (though a bit tricky), see #1566 for details. |
@Mithgol I get a:
when running
Any idea? |
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 |
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 |
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. |
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. |
A brief follow-up on the |
Also, I tried It does not seem to prevent the same node-webkit's RANDR-related Xlib error. Useless. |
Reasons that Node-Webkit would be the better headless browser:
|
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. |
+1 |
"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? |
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. |
@rogerwang I need NWJS application that combines Node and Browser DOM rendering and can run in pure CLI mode when needed. Agree with @polpo |
@rogerwang my NWJS application use the Node Api AND the DOM, Canvas, WebGL, WebWorker, to compute images at server side. |
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? |
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:
|
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 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 (I must admit that Travis CI instances have |
@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. |
(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:
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. |
Why can't you use Phantomjs? |
phantomjs_long_page.pdf phantomjs doesn't support page-breaks and doesn't go through a print pipeline in general. See attached files for differences. |
Can you please share your Phantomjs settings? |
@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. |
PhantomJS maintainer stepping down after Google's headless Chromium announcement |
Announcement itself: https://www.chromestatus.com/features/5678767817097216 |
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 Please note that in upstream, there are 2 browsers in the Chromium binary (headless, and the normal one which we've been using). When 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. |
Update: the upcoming 0.23.0 beta will support headless usage as in upstream: https://developers.google.com/web/updates/2017/04/headless-chrome |
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:
but file not created, express server also not started |
@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 |
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. |
Hi, But i get a Gtk-WARNING : cannot open display What's wrong ? Thank you |
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. |
@BoostIO funded this issue with $10. Visit this issue on Issuehunt |
@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt |
Any update on the issue? |
@0maxxam0 has funded $2.00 to this issue.
|
Any news here ? No update since times |
I'm looking into it |
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.
The text was updated successfully, but these errors were encountered: