fileAssociations + makeSingleInstance - "open-file" event doesn't always fire

[payitforwardnow]

• 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

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[payitforwardnow]

The questions are "Am I Crazy", "Am I Missing Something Obvious" and "Am I Expecting Something That I Shouldn't"?

[payitforwardnow]

Similar to #4403 and #9925. Both were closed so I opened a new issue.

[pabloedorasware]

any update on this? do you know of any workaround until fix is released?

[sofianguy]

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron v4.2.x or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

[sofianguy]

Thank you for your issue!

We haven't gotten a response to our questions in our comment above. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.