The day before yesterday (April 27), the righteous bowels of the Intel
Open Source Technology Center (and this is the Center that hshhhhh reviewed a week ago in the blog Penguin Cookies ) published the new version of the
node-webkit engine - the mighty Node and WebKit
(or rather, not just WebKit, but Chromium - and later, probably, Blink), which provides a quick and uncomplicated creation of
GUI applications using web
development methods (JavaScript code using Node.js API, and an HTML interface on CSS) under Windows, Mac OS X and Linux operating systems.
The new version has the
number 0.5.1 ; on its basis, it is easy to create and launch, for example, the following window:
![[screenshot]](https://habrastorage.org/storage2/7d8/8e0/416/7d88e041690b95897ba69161b3789127.png)
')
One of the previous versions of node-webkit (0.4.1) I
had a chance to review in early February, and now it's the end of April outside. It is time to talk about all the changes that accompanied the release of
version 0.4.2, after her 0.5.0, and then 0.5.1 finally. I tell:
- The biggest change was the support for printing pages: the window.print () function started . Unfortunately, the supplementing its ability to preview pages in their printed form has not yet been implemented (but this is planned in version 0.5.2).
- The Window object has a new function capturePage () that allows you to get a screenshot of the part of the page visible in the window. There is an example.
- In order to partially protect the source code, a new nwsnapshot utility appeared , which provides a preliminary compilation of the specified javascript file into machine-dependent code that can be distributed instead of the source code if the source code does not want to be shown to anyone.
- The icon for the Macintosh system tray can now have an alternative (active) style. Also, there was support for the shortcut keys "CMD" and "` " for switching between windows on Macs.
- The <input type = "file"> element, which serves to open dialog boxes for opening or saving a file, can now be supplied with the nwworkingdir attribute, the value of which indicates that subdirectory in the file system where the dialog should start working. Thus, if the program correctly guessed where the user stores his files, then the user is relieved of the extra efforts to oblige his file system.
- The new security system prevents the use of Node.js code by pages loaded in the <iframe> when the <iframe> element is provided with the nwdisable attribute.
- Special efforts were made to ensure that the application from the <iframe> could not get out and take the whole window. First, the X-Frame-Options header in the HTTP response header is ignored . Secondly, if the <iframe> element is supplied with an attribute with the name nwfaketop invented by me, then the page loaded in the <iframe> receives fake window.top , window.parent, and so on values, so that it cannot understand that it is in the frame, and I could not get out of the frame.
(So far it turns out that, for security reasons, you will have to specify both
nw-attributes: <iframe nwdisable nwfaketop src = " ...
"> ...
</ iframe> . This
non-trivial phenomenon is temporary; it is planned to be fixed in a future version of
node-webkit. )In addition, both main components of the engine were updated:
Node.js - to version 0.10.5 (as can be seen in the above screenshot),
and Chromium - to version 27.0.1430.0.To all developers who used earlier versions of the
node-webkit engine
, I recommend to update them immediately to a new version for greater security if the application’s work was related to loading untrusted pages into frames.