⌘1 sometimes stops working in other apps

[glyph]

---

Please include:

• Operating System:

  ProductName:	Mac OS X
  ProductVersion:	10.13
  BuildVersion:	17A405
  

• Clear steps to reproduce the issue:
  Run the application for a while. Eventually, the ⌘1 hotkey starts getting captured regardless of where my keyboard focus is until I restart the application.

I am only logged in to one Zulip, but if I select settings, ⌘Tab away, and then hit ⌘1 in another app when in this state, I can see it switch back to that Zulip rather than the Settings window, so I assume that for those with multiple Zulips it would globally capture ⌘2, etc.

[akashnimare]

⌘1 sometimes stops working in other apps

@glyph can you define sometimes here? Does it happen all the time or in any specific case like when you switch to other apps using ⌘Tab?

[cedricium]

@zulipbot claim

[cedricium]

Hey @glyph, I'm going to be trying to fix this issue. In addition to defining what sometimes means, is there a specific application (when you CmdTab) you're using that you see this issue happen with or is it multiple applications? I'm attempting to reproduce and haven't been able to so far. Thanks!

[timabbott]

@cedricium it seems likely the other application is irrelevant, and that the problem is that we're in some circumstance failing to unregister the hotkey from the OS...

[cedricium]

@timabbott that makes sense. I'm having trouble reproducing, am I understanding the issue correctly:

1. In Zulip app, open the Settings page. Settings page is the active window.
2. Switch to another application using CmdTab. Different application is now focused.
3. Use the Cmd1 shortcut in different application.
4. Focus the Zulip app - active window is now the first sever (no longer the Settings page).

There's some sort of timing in between switching applications and using Cmd1 which causes the issue, but is the right way to go about it?

[akashnimare]

I'm guessing this is what @glyph experiencing -

• Open Zulip app, add a server
• Open setting page
• CMD+1 should switch to the first added server (this is expected)
• Now open other app, for an example Chrome
• Press CMD+1, which should open the first tab of Chrome but instead it focuses on Zulip app and opens the first server.

I can't reproduce the last step. I'm not sure if we have to unregister CMD+1 when window loses focus, hidden etc since electron-localshortcut automatically unregister the shortcut for us.

[cedricium]

I still haven't been able to reproduce this issue, and looking at the code where the keyboard shortcuts for switching between servers gets set, I don't see anything that explicitly stands out which would cause this issue 😕

[akashnimare]

@glyph can you help us reproducing this issue. We've both tried to reproduce and read the code, and don't see how we can investigate further without more info 😕

[akashnimare]

@vbNETonIce can you reproduce this issue on Windows?

[penCsharpener]

no, never ran into this but I also don't really add new servers anymore (if that is relevant to the issues - just skimmed over this)

[akashnimare]

Hmm, thanks.

I also don't really add new servers anymore

Yeah, it's irrelevant. It could happen when you have only one server as well (since CTRL+1/⌘1 gets assigned).

[glyph]

I am also noticing this with ⌘R now, and it seems to happen almost every day now, which means part of my web-dev workflow is to quit zulip 3 or 4 times per day.

Anything I can do to make this more reproducible?

[glyph]

My OS is now

ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B48

so not fixed by Apple :)

[glyph]

I am not sure what the exact race condition is here, but https://www.npmjs.com/package/electron-localshortcut looks like a horrible hack that seems like a magnet for exactly this kind of bug. It is not appropriate for a mac app to register global hotkeys just to avoid populating the menu bar. Please just put the stuff into a menu like the human interface guidelines recommend, and this global registration race won't even be possible.

[cedricium]

Hey @glyph, can verify the steps taken to reproduce this? Or if it's not always reproducible, just outline what happens when you use ⌘1 / ⌘R. I didn't understand your original comment about when you opened this issue.

Would love to help get this fixed!

[timabbott]

@akashnimare what do you think about replacing that library? I am partial to @glyph's argument here.

[glyph]

@cedricium I just launch Zulip and wait for it to steal my hotkeys ;). What happens when I press ⌘1 with Zulip in the background is that it does exactly what ⌘1 does with Zulip in the foreground, whatever that would be.

[akashnimare]

I know electron-localshortcut has created problems in past but I guess we fixed most of the issues. I updated my macOS from 10.12 to 10.13 but couldn't repro this hotkey bug. @glyph
just to make sure that we're on same page can you confirm that you're using the latest version which is v1.5.0 via clicking on Menu > About Zulip -

[glyph]

Yes, I'm using 1.5.0.

[glyph]

I know electron-localshortcut has created problems in past but I guess we fixed most of the issues.

Only on your computer, apparently ;-).

The way electron-localshortcut works is fundamentally a bad idea. Calling APIs like this for no reason is the sort of thing that gets you banned from the mac app store, flagged as malware, etc. Global hotkeys should only be mapped if you are clearly calling this out to the user as global.

To help track this down, in case it's an interaction with something else, a list of applications I routinely run are:

• Sip (the old mac app store version)
• OmniFocus
• Emacs, mituharu's "mac port" version, installed from homebrew
• 1password (mac app store version)
• Dropshare
• Docker for Mac
• Codepoints
• iStat Menus
• Google Chrome
• Moom
• SizeUp
• Dash
• iTerm2

There's nothing I can think of that I do with Zulip, or with any other app, that causes it to start grabbing the keyboard focus in the background; it just runs for a while and then I notice my command keys aren't doing what I expect.

[olbrich]

I see this pretty consistently with iTerm in particular. Switching to Zulip (or quitting it) releases the cmd-1 key back to the system. I can consistently get this to happen when I switch spaces.

[akashnimare]

Okay, so we need to remove electron-localshortcut library which is the root cause of this issue. I'm looking for ways to implement same shortcuts without the use of this module which should fix this issue.

[akashnimare]

I have pushed a fix in remove-electron-localshortcut. I have removed electron-localshortcut dependency and now using electron's default globalShortcut api to register the shortcuts. Can somebody cross check if it works as expected?

[glyph]

The problem with localshortcut is that it uses globalShortcut. If anything this would be worse.

[akashnimare]

@glyph I have completely removed electron-localshortcut and globalShortcut. Now we only rely on menu for shortcuts - zulip/zulip-electron@bcb8ffb.

[akashnimare]

Just released 1.6.0-beta. @glyph, @olbrich please update app (via selecting Get beta updates from setting option or download manually through this link) and see if it fixes this issue.

[glyph]

@akashnimare Fantastic. Thank you so much for the fix - and for fixing it the Right Way!

I got the auto-update notification and installed it, and despite using it for longer than the average time where this would trigger, with all my usual apps running, I have not had my hot keys get grabbed. Seems to be working great!

It's hard to be totally sure since I don't know what I did that would reliably trigger it, but at this point I'd be confident closing this bug if I were you. (Hopefully @olbrich can confirm.)

[olbrich]

seems good so far, I can switch spaces without issue.

[akashnimare]

Awesome. Glad we hunt down the root cause of this issue. @olbrich, @glyph thanks a lot for helping us in debugging ❤️ Feel free to re-open if it happens again.