Consider an electron application that uses `execFile` to run a script
that lives within the application code base:
```coffee
child_process = require 'child_process'
child_process.execFile __dirname + '/script.sh', (error) ->
throw error if error?
```
An application like this will fail when being packaged in an `asar` with
an following error:
```
Error: spawn EACCES
```
Electron overrides certain `fs` functions to make them work within an
`asar` package. In the case of `execFile`, the file to be executed is
extracted from the `asar` package into a temporary file and ran from
there.
The problem is that during the extraction, the original permissions of
the file are lost.
We workaround this by:
1. Extending `asar.stat` to return whether a file is executable or not,
which is information that's already saved in the `asar` header.
2. Setting execution permissions on the extracted file if the above
property holds true.
Fixes: https://github.com/atom/electron/issues/3512
When the browser process is busy, calling webview.send (a method that appears
on its face to be non-blocking) will actually block, because most webview methods
are remoted to a guest view instance in the browser. Instead, define a few methods
which will instead send its call over an async IPC message.
Some of the roles in menu-item use methods on BrowserWindow instead of
WebContents which outputs a deprecation warning.
I changed it to use the correct methods.
- Links to docs in the default app, pointed to the docs in the master
branch. I changed them to point to the docs that match Electron's
version.
- Added Electron's version to the header of the default app, so it will
be easier to figure out what version is currently running.
Adds the desktop window type referenced in https://github.com/atom/electron/issues/2899 for compatiblity with the linux version. Note that on Mac OS X, the desktop window cannot receive input events (seems to be a limitation of being behind the desktop).
In this diff I also removed the `standardWindow` option from the docs, in favor of an additional `textured` value for window `type` on Mac OS X. The old `standardWindow` option continues to work, but seemed more confusing. If this seems like a bad idea, I can revert that change.
Spent a while tracking down `Error processing argument -1`, caused by a missing param (`app.exit()` now takes an exit code.) Improve the rpc-server so that it prints the function name when possible, so it's much easier to identify which remote call is causing the error.
