Atom Shell applications not detaching from shell when started via symlink on OS X 10.10

[kopischke]

I’ve run into an odd issue testing the Neovim.AS Atom Shell app, where I cannot get its window to accept keyboard input on OS X 10.10.2 when I start it via the atom-shell CLI; instead, all keyboard input goes to the last active application – in the case of the screenshot, the shell in which Neovim.AS was started:

I also can’t switch to the window with Cmd-Tab, its OS X menu does not display, and the only way to quit it is issuing ^C in the originating shell. I have reproduced the issue with another, more straightforward Atom Shell app, pamm-atom, incidentally showing that the apps are responding to mouse input (Vim not being a really good object to judge that :)).

If I start pamm-atom via the GUI, none of the above occurs (not testable with Neovim.AS due to the Grunt requirement and lack of app folder).

Configuration:

• OS X 10.10.2 German locale, German keyboard input. I’ve tried disabling my input hacks (specifically, Seil and Karabiner) and switching to a US keyboard map, but none of that helped.
• atom-shell version 0.21.2 64 bit without symbols, downloaded from the Releases pages. The Atom Shell app runs without a hitch by itself, as does Atom the editor (which accepts my keyboard input like a champ, I hasten to add).
• OS X stock Terminal.app running the system bash (GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)). The above screenshot shows a version running with TotalTerminal injected, but the same issue occurs within standard terminal windows [EDIT: and in iTerm 2].

[advdv]

Having the same issue with the same OSX version, actually also experience the issue with nw.js - Feeling like I missed something here.

[zcbenz]

It seems that OS X doesn't treat the window as a normal window and prevents it to get focus, I tried OS X 10.10.2 with neovim.as app, but could not reproduce.

[leungwensen]

having the same issue with the same osx version. is there any solution available now?

[kopischke]

If @zcbenz cannot reproduce, the interesting question is if we all have some configuration in common?

• non-English locale (German in my case)
• non-English keyboard map (German in my case)
• using 3rd party keyboard extensions (Seil and Karabiner in my case)
• using a global hotkey hooking app (Alfred in my case)
• using a window management app (Moom in my case)
• using a screen management app (f.lux in my case)

(scraping the bottom of the barrel a bit with these last two, but I’ve tried to include everything I can think of possibly affecting input and window behaviour) – @advanderveer, @leungwensen how about you?

[advdv]

@kopischke Did you run atom from the cli e.g $> atom-shell ../app-dir/ while trying to reproduce? How about the terminal you are using? (I'm using default Terminal.app) For the list:

• non-English locale (US)
• non-English keyboard map (US)
• 3rd party keyboard nooks (nope)
• using a global hotkey hooking app (nope)
• using a window management app (nope)
• using a screen management app (nope)

[kopischke]

Did you run atom from the cli e.g $> atom-shell ../app-dir/ while trying to reproduce? How about the terminal you are using?

@advanderveer see my original report, it’s all there. I haven’t been trying to reproduce, I’m the OP :).

[advdv]

Sorry my question was aimed at @zcbenz

[kopischke]

Sorry my question was aimed at @zcbenz

Thought so :). Terminal type is unlikely to play a part in this, tho, as I have reproduced the issue in iTerm 2 in the meanwhile…

[leungwensen]

@kopischke in my case:

• non-English locale (Chinese)
• non-English keyboard map (US)
• 3rd party keyboard nooks (nope)
• using a global hotkey hooking app (nope)
• using a window management app (nope)
• using a screen management app (nope)

hope this would help

[d--b]

Same issue here.
Probably related: application menus do not work either... The menu bar remains the Terminal menu bar.

[d--b]

Not ideal but running:

nohup atom.app myapp

will work

[kopischke]

The menu bar remains the Terminal menu bar.

Yup, that was what I meant by “its OS X menu does not display”. Good call about nohup: I tried backgrounding the process, but that option slipped my mind. However, that specific workaround is just forcing atom-shell to do what it should do anyway: detach from its originating shell; the underlying bug still needs to fixed.

[pwestling]

Not sure whether this will help you guys out, but I hit this same issue and discovered that it was because my atom-shell command was a symlink - specifying the full path to the Atom command within Atom.app solved the issue for me.

[kopischke]

Confirmed. Using the full path works. Thanks @pwestling.

[builden]

sublime text 3 start from terminate can input on OS X 10.10.3

[zcbenz]

I have been using Electron on 10.10 for months and didn't observe this bug any more, I'm assuming it has been fixed by OS X.

[jordansissel]

I appear to be having the problem described in this ticket - OSX keyboard input doesn't work, window focus seems ignored, and no menubar. Mouse input works as i can select text within the Electron app (neovim-e).

% Electron --version
v0.35.1

# The electron app:
% git remote -v
origin  https://github.com/coolwanglu/neovim-e (fetch)
% git rev-parse HEAD
2a05427a05c50818750689190edab6df621e4e8e

On OSX 10.11.1

I have no experience with electron, so I may not be of much help debugging or speculating what is causing this.

[iamitava]

FWIW, this discussion was the top result when I googled "os x symlink app doesn't get keyboard focus", and my issue was not even for neovim or Atom Shell. I am trying out Spacemacs, and after installing emacs (brew install + brew linkapps) I unnecessarily created a symlink to the linked app. Starting emacs via this symlink had the same issues—no keyboard focus, nothing in the menubar, etc. Using the full path worked. Not sure what's going on, but it's not just Atom Shell.

(I'm on El Capitan 10.11.4)

[zcbenz]

I'm closing this as won't fix since this is apparently a bug of OS X, and there is no way to fix this on app's side.