Currently, when calling `copyFileOut`, the original extension from the
file is lost, and a generic `*.tmp` is added instead.
This becomes problematic in the scenario where we use
`child_process.execFile` on a Windows Batch script that lives inside the
`asar` package.
Windows relies on the extension being present in order to interpret the
script accordingly, which results in the following bug because the
operating system doesn't know what do to with this `*.tmp` file:
```
Error: spawn UNKNOWN
```
Steps to reproduce:
1. Create a dummy batch script (test.bat):
```
@echo off
echo "Hello world"
```
2. Create an electron app that attemps to call this script with
`child_process.execFile`:
```js
var child_process = require('child_process');
var path = require('path');
child_process.execFile(path.join(__dirname, 'test.bat'), function(error, stdout) {
if (error) throw error;
console.log(stdout);
});
```
3. Package this small application as an asar archive:
```sh
> asar pack mytestapp app.asar
```
4. Execute the application:
```sh
> electron.exe app.asar
```
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.
- Consolidate logic that applies view dimensions into a function
- Use `NSVariableStatusItemLength` instead of trying to sync status item width
- Use modern Obj-C syntax `@[], @{}` in a few places
- Recompute view bounds after updating image in `setImage:`
