Issue 1:
Electron Version:2.0.7

Electron Builder Version:20.27.1

Operating System (Platform and Version):OS X 10.11.6

Last known working Electron version: unknown

Expected Behavior

If app IS already running and the user opens any file with a file extension handled by the app using "Open With" or double clicking on a file where the app is the default editor, the running app should receive an "open-file" event and no other app should be launched. If the app is NOT already running and the user opens a file with a file extension handled by the app using "Open With" or double clicking on a file where the app is the default editor, the app should be launched with a subsequent open-file event.

Actual behavior

Sometimes the RUNNING app receives an open-file event sometimes it does not. Very strange behavior seems to be associated with a) how the app is initially launched and b) what other apps are running at the time the app is launched. When app IS already running, only files with extensions where the app is the DEFAULT handler will cause an open-file event to be received by the running app. Any other file that is opened using "Open With" sends the open-file event to the new app that is quitting so the RUNNING app never receives the event.

To Reproduce

I've created a fork of electron-quick-start. Simply clone, install and build. The app must be built on OSX for FileAssocitions to work. The only files I modified from the quick start are the package.json file and the main.js (my code is marked with DAM).

To test you will need to create a few files to demonstrate the problem. The extensions this app will handler are .eds, .edsx, .pdf, .tif and .tiff.

"fileAssociations": [
{
"ext": [
"eds",
"edsx"
],
"description": "EDS file extension",
"name": "EDS",
"role": "Editor"
},
{
"ext": "pdf",
"description": "PDF file extension",
"name": "PDF",
"role": "Editor"
},
{
"ext": "tif",
"description": "Scanned TIF Document",
"name": "TIF",
"role": "Editor"
},
{
"ext": "tiff",
"description": "Scanned TIFF Document",
"name": "TIFF",
"role": "Editor"
}

Make sure at least one of these files extensions is not already handled by another app so that you can see the differences in behavior when the app is the DEFAULT editor and when it is an alternate. I will assume going forward that this app will be the DEFAULT editor for .eds and .edsx files.

In my example I created the following files:

test1.eds - default handler is this app

test1.edsx - default handler is this app

test1.pdf - default handler is Preview

test1.tif - default handler is Preview

test1.tiff - default handler is Preview

The contents of the file doesn't really matter; however, you should use a valid .pdf file if you have one. You can then duplicate the .pdf file to create all the other files. Before each test make sure the app is not running (including helpers) using the Activity Monitor.

**Note: I've found that you have to launch the app at least once for the file associations to be active. I thought installing the app would set this up; however, if you install the app and then use "Open With" on the .pdf file (for example) the Preview app opens instead. After you launch the app the first time doing the same thing will open the app correctly. This may or may not be a separate issue.

**

Test #1 - Launch the app manually via the Applications folder. Now open each individual test file using "Open With" via context menu. Note that only the .eds and .edsx files generate an open-file event. Quit the app.

Test #2 - Launch the app by double clicking on the .eds or .edsx file (assuming the app is the default editor for these file types). Now open the remaining files using "Open With". Note that the same thing happens as in test #1. Quit the app.

Test #3 - Make sure the Preview app is not running. Launch the app by using the "Open With" on the .pdf file. The app should launch. Now open the all the other files using "Open With". You should see that some result in the open-file event firing and some do not. The .eds and .edsx files do not fire the open-file event using "Open With"; however, if you now double click on them it works. Quit the app.

Test #4 - Drag the app to the Dock. Now drag the .pdf file to the app on the Dock. The app opens as expected. Now open the .eds, .edsx, .tif and .tiff files using "Open With". Note that the .tif and .tiff fail. Now double click on the .eds and .edsx files. They work. Now try using "Open With" on the .pdf file (the one you initially dragged to the app on the Dock). That doesn't work. Crazy right? Quit the app.

Observed results - in each case where the RUNNING app fails to receive the open-event there is a separate log file created. This indicates that the app is actually launched a second time where it then receives the open-file event and immediately quits. I modified the log handler to create a new log file for each app invocation. This way you can see the logs in the RUNNING app as well as the logs generated by the new app instances. The RUNNING app sometimes receives the open-file event and sometimes it doesn't.

Here is the contents of the log the second app generates (what I believe is a bug)

[2018-08-11 13:02:34.217] [info] quitting because app already running
[2018-08-11 13:02:34.291] [info] ----------------------- app will-finish-launching -------------
[2018-08-11 13:02:34.407] [info] ----------------------- app open-file ------------------------ /Users/popeye/Data/MyProjects/git/testData/test1.tif
[2018-08-11 13:02:34.408] [info] open-file - /Users/popeye/Data/MyProjects/git/testData/test1.tif

At the same time the RUNNING app generates the following additional logs (notice no open-file event)

[2018-08-11 13:02:34.215] [info] checking to see if app already running
[2018-08-11 13:02:34.215] [info] isSecondInstance? argv, [ '/Volumes/electron-quick-start 1.0.0/electron-quick-start.app/Contents/MacOS/electron-quick-start', '-psn_0_2298417' ]
[2018-08-11 13:02:34.215] [info] isSecondInstance? workingDirectory, /
[2018-08-11 13:02:34.216] [info] deeplinkingUrl = ??
[2018-08-11 13:02:34.216] [info] executing js -
var elem = document.createElement("div");
elem.textContent="deeplinkingUrl = ??";
document.body.appendChild(elem);

This can't be the intended results. The problem is that the RUNNING app never gets an open-file event "in certain situations" based on how the app was launched and what other apps are running at the time (default editors).

In the screen shot I provided you will see that the 2 file extensions .eds and .edsx work correctly by double clicking on them OR using the "Open With". I suspect this is because the app is the DEFAULT handler for these types of files. Other extensions like .pdf or .tif/.tiff are not handled properly (IMHO).

Now since this is my first reported issue I have to assume that I am doing something incorrectly and/or reading the documentation incorrectly. If that is the case I apologize in advance for taking up your time and would appreciate some helpful words of wisdom.

Thank you in advance for your time and consideration.

$ git clone https://github.com/payitforwardnow/electron-quick-start-14029
$ npm install
$ npm run build

Screenshots

Test1 & Test2

Test3

Test 4

Test Files

Log Files

Issue 2:
Is your feature request related to a problem? Please describe.

running many electron apps uses much memory and harddisk space overhead

Describe the solution you'd like

electron should run as a daemon so that more then 1 app can share functions

Describe alternatives you've considered

create os level bindings for all functions something like nativ apps done via cordova

Additional context