Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto Launch opens terminal on OSX #28

Closed
luhfilho opened this issue May 9, 2016 · 31 comments
Closed

Auto Launch opens terminal on OSX #28

luhfilho opened this issue May 9, 2016 · 31 comments

Comments

@luhfilho
Copy link

luhfilho commented May 9, 2016

Hi,

I have implemented auto launch and it works perfectly at windows and linux, but, at osx the terminal opens and if I close it, the app is terminated.

Follow the code below.

var AutoLaunch = require('auto-launch');

var appLauncher = new AutoLaunch({
    'name': appName
});

appLauncher.isEnabled().then((enabled) => {
    if (enabled) return;
    return appLauncher.enable()
}).then((err) => {});

Are there any missing configurations?

@Dihgg
Copy link

Dihgg commented May 9, 2016

@luhfilho
I also have this problem, within a similar configuration.

@CHENGP618
Copy link

some here

@luhfilho
Copy link
Author

@CHENGP618 @Dihgg
I solved my problem with this fix

if(process.platform !== 'darwin')
{
    //auto lauch test
    var appLauncher = new AutoLaunch({
        'name': appName
    });
    appLauncher.isEnabled().then((enabled) => {
        if (enabled) return;
        return appLauncher.enable()
    }).then((err) => {});
}
else
{
    const username = require('username');
    username().then(username => {
        //=> 'sindresorhus'
        var osxExecutable = '/Applications/AppName.app';
        var osxStartFile =  '/User/'+username+'/Library/LaunchAgents/AppName.plist';

        var exists = fs.existsSync(osxStartFile);
        if (!exists) {
            var osxData = '<?xml version="1.0" encoding="UTF-8"?>\r\n'+
                            '<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\r\n'+
                            '<plist version="1.0">\r\n'+
                            '<dict>\r\n'+
                                '<key>ProgramArguments</key>\r\n'+
                                '<array>\r\n'+
                                '    <string>'+osxExecutable+'</string>\r\n'+
                                '</array>\r\n'+
                                '<key>RunAtLoad</key>\r\n'+
                                '<true/>\r\n'+
                                '<key>'+appName+'</key>\r\n'+
                                '<string>'+appId+'</string>\r\n'+
                            '</dict>\r\n'+
                            '</plist>';
            fs.writeFile(osxStartFile, osxData);
        }
    });
}

I used username module, to get OS username folder to save plist file, this way, the OSX system will open your app on startup.

@Dihgg
Copy link

Dihgg commented May 16, 2016

@CHENGP618 @luhfilho, Also worked for me, a kind of workaround.

@nickav
Copy link

nickav commented May 17, 2016

What version of Mac is this happening on? Works for me on 10.9.5

@luhfilho
Copy link
Author

@nickaversano 10.11.5 version

@CHENGP618
Copy link

CHENGP618 commented May 18, 2016

@Dihgg @luhfilho couldn't work for me, version 10.11.4, anything special to take care?

<key>Label</key>

<string>com.sigilium.addressbook</string>

<key>ProgramArguments</key>

<array>

  <string>/Applications/sigiliumaddressbook.app</string>

</array>

<key>RunAtLoad</key>

<true/>

@djpereira
Copy link

djpereira commented May 26, 2016

I have the same experience on OSX 10.11.4 and I am using electron with electron-builder.
"electron-builder": "~3.25.0",
"electron-prebuilt": "~1.1.3",

I noticed that in OSX it is creating a Login Item for the user that points to a script within the app package, instead of pointing to the app itself (see below), at least for me.

image

If the login item would just point to the application itself, it would work as intended, with no terminal window.

Looking at the code, if you use electron and do not specify opts.path when you call the AutoLaunch constructor, it will just pick the path from process.execPath (see https://github.com/Teamwork/node-auto-launch/blob/master/src/index.coffee#L23).

After that fixOpts is called which in turns calls @fixMacExecPath that "corrects the path to point to the outer .app" if you are running on "darwin". @fixMacExecPath uses a regular expression to correct the path, and this could be where the issue is for the ones running into the problem.

@nickav
Copy link

nickav commented May 27, 2016

@djpereira what is your process.execPath on OSX 10.11? On 10.9 it is: ./node_modules/electron-prebuilt/dist/Electron.app/Contents/MacOS/Electron
When run through @fixMacExecPath, it truncates everything after Electron.app which gives the desired effect.

The interesting thing to note is that @fixMacExecPath uses MacOS\/Electron in its regular expression. When running packaged electron apps, Electron won't match the app name.

@djpereira
Copy link

Thanks for asking @nickaversano. The process.execPath for in OSX 10.11 for our app is /Applications/My Electron App.app/Contents/Frameworks/My Electron App Helper.app/Contents/MacOS/My Electron App Helper

We do have white spaces in our app name, not sure if that's an issue.

@nickav
Copy link

nickav commented May 27, 2016

@djpereira this definitely isn't a spacing issue. Happens to me on an app without spaces. Like you mentioned, I think this is happening because @fixPath fails to return the correct application path. I'm fairly confident this happens in packaged applications because 'Electron' would be renamed to the new app name but @fixMacExecPath uses a regular expression with a hardcoded 'Electron' which would fail to match.

@nickav
Copy link

nickav commented May 27, 2016

For anyone running into this issue for Electron apps, manually setting path to the outermost application path works. Here's my temporary workaround (tested on 10.9 and 10.11):

var appPath = app.getPath('exe').split('.app/Content')[0] + '.app';
appLauncher = new AutoLaunch({
  name: app.getName(),
  path: appPath,
});

@djpereira
Copy link

Thanks for the workaround @nickaversano. This worked very well for me.

@orther
Copy link

orther commented Jul 22, 2016

For NW.js the solution provided by @nickaversano works (only tested with [email protected]).

The following is code from my project. It fixes the path on OS X and removes the bad login item nwjs Helper that could exist from before fix was put in place:

function getCurrentApplicationPath() {
    if (global.process.platform === 'darwin') {
        return global.process.execPath.split('.app/Content')[0] + '.app';
    }
    return null;
};

const bootLauncher = new AutoLaunch({
    name: APP_NAME,
    path: getCurrentApplicationPath(),
    isHidden: false,
});

// remove any existing `nwjs Helper` login item on app start
bootLauncher.removeNwjsLoginItem();

@adam-lynch
Copy link
Contributor

Hey everyone, could you please confirm if #38 fixes this?

@mzdr
Copy link

mzdr commented Sep 1, 2016

Nope, I think there is still a bug. Will share details in #38.

@todbot
Copy link

todbot commented Sep 8, 2016

I was also having this problem (I've not yet tested #38), but here's the hack I used on Electron to get it to work for me:

var appPath = app.getAppPath();
if( process.platform === 'darwin' ) { 
    appPath = path.resolve( appPath, '../../..'); // MyApp.app/Contents/Resources/app.asar
}
var AutoLauncher = new AutoLaunch({
    name: 'Blink1Control2', 
    path: appPath
});

(I'm using asar to pack my app, which is why there's 3 '..')

@adam-lynch
Copy link
Contributor

OK I've just released 5.0.0. Please give that a try and let me know if the issue persists. If so, also try the new Launch Agent option.

If it still persists, I'm going to need more information and probably an example app. I need the versions of what you're using, the options being passed to our module, if you're using it in the Electron main or renderer process, and what your process.execPath is.

If your problem has been solved, please let us know too. Thanks.

@omichelsen
Copy link

The issue persists, still seeing the Terminal on Mac. Windows is fine.

@sujkh85
Copy link

sujkh85 commented Nov 1, 2016

some here
osx v10.11.6
eletron v1.4.x

    new AutoLaunch({
            name: 'me',
            path: app.getPath('exe'),
            isHidden: false,
            mac:{
                useLaunchAgent:true
            }
        });

@sujkh85
Copy link

sujkh85 commented Nov 1, 2016

@orther right

let appPath = app.getPath('exe').split('.app/Content')[0] + '.app';
new AutoLaunch({
            name: 'me',
            path: appPath,
            isHidden: false,
        });

@adam-lynch
Copy link
Contributor

@omichelsen @sujkh85

Are you using Electron? If so, in the main or a renderer process?
Is there any chance you could share a simple sample app which reproduces this?

@omichelsen
Copy link

Using OSX 10.12.1 and Electron 1.4.3. Triggering this in the main process. Using the "fix" @sujkh85 suggests (only on Mac) fixes it for me.

@sujkh85
Copy link

sujkh85 commented Nov 29, 2016

@adam-lynch yes use Electron
use main process

function initAutoLaunch() {
	if (autoLauncher) {
        return;
    }
	let appPath = process.platform === 'darwin' ? (app.getPath('exe').split('.app/Content')[0] + '.app') : app.getPath('exe')

    autoLauncher = new AutoLaunch({
        name: 'myApp',
		path: appPath,
                isHidden: false,
		mac:{
			useLaunchAgent:true
		}
    });
}

ipcMain is electron object

    ipcMain.on('SET_AUTO_LAUNCH', (event, arg) => {
        let result = arg.enabled ? autoLauncher.enable() : autoLauncher.disable();
        result.then(() => {
           console.log('autoLaunch','autoLauncher success');
        }).catch(() => {
           console.log('autoLaunch','autoLauncher error');
        })
    });

@fretman92
Copy link

Pull request that can solve that: #34

@guerrerocarlos
Copy link

guerrerocarlos commented Feb 23, 2017

Meanwhile, I pushed a patched version of this module to npm: auto-update-patched

npm install auto-launch-patched

var AutoLaunch = require('auto-launch-patched');

So it can be used instead, while #34 is merged into auto-launch.

@ghost
Copy link

ghost commented Mar 23, 2017

I have found a difference between usage of useLaunchAgent to launch electron app:

If true, you have to specify path as app.getPath('exe') provides (without split last part)
If false: you have to split path to be blablabla.app

Does it work for all?

@tiangolo
Copy link

I was having this issue in macOS, for an electron app built with electron-builder.

But after changing the option to set the auto launcher using a "launch agent" as described in https://github.com/Teamwork/node-auto-launch#launch-agent it worked without a problem.

Here's the relevant code I had:

const autoLaunch = new AutoLaunch({
    name: app.getName(),
  });

And I changed it to:

const autoLaunch = new AutoLaunch({
    mac: {
      useLaunchAgent: true,
    },
    name: app.getName(),
  });

That solved the issue, at least in my case.

@jssuttles
Copy link

jssuttles commented Aug 31, 2017

For nwjs .apps, the solution is definitely along the lines of @orther's solution. That works.
(without the .removeNwjsLoginItem which is old)

@adam-lynch
Copy link
Contributor

Apologies, we've neglected this project a little bit. We're going to fix that though, see #64. I'm going to put in some time this Saturday. If someone could provide a simple app by then that reproduces this (or if it's simply the Electron hello world app), then that would help things along.

@adam-lynch
Copy link
Contributor

I've just published 5.0.2 which should fix this. Let me know if not.

@luhfilho @djpereira @nickaversano @guerrerocarlos since you all looked into the code a bit... I don't know if you saw #64 but we're looking to bring add some contributors/maintainers to help with:

  • Improving documentation.
  • Troubleshoot, triage, and reproduce issues on your machine.
  • Fix bugs.
  • General maintenance (dependencies, etc).
  • Suggest & add features.
  • Review, test, and merge pull-requests from other contributors.
  • Anything else you can think of which would help.

Would you be open to that? I can give you access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests