Opening Settings View with all windows minimized does nothing

[jsejcksn]

(This is related to atom/tree-view#690)

When I try to open Settings using ⌘+, (macOS standard keyboard shortcut), nothing happens if all of my Atom windows are minimized.

Reproduction Steps:

1. Open one or more Atom windows
2. Minimize all windows
3. Press ⌘+,

Expected behavior: Settings opens in a new window in a new tab Observed behavior: Nothing happens

Atom version: 1.11.1 OS and version: macOS 10.12

Installed packages:

• atom-beautify
• atom-mac-terminal
• color-picker
• compare-files
• flatwhite-syntax
• gist-it
• json-converter
• lines
• linter
• linter-csslint
• linter-htmlhint
• linter-js-standard
• linter-jshint
• linter-jsonlint
• linter-less
• linter-xmllint
• minimap
• pigments
• standard-formatter

Additional information:

• Problem can be reproduced in safe mode:
  I don't know what safe mode is in macOS
• Problem started happening recently, didn't happen in an older version of Atom:
  No
• Problem can be reliably reproduced, doesn't happen randomly:
  Yes
• Problem happens with all files and projects, not only some files or projects:
  Yes

Screenshots and more details

I think the issue here is that the ⌘+, keybinding has two entries by default in a vanilla install on macOS, and I'll go into further behavioral description below:

Keybindings shows that ⌘+, is assigned to both application:show-settings and settings-view:open. I have no idea why it was designed this way, but here is where it starts to cause problems.

This is what the menu bar typically looks like in Atom when a window is open (I'll get to why this is relevant in a moment). When I press ⌘+,, a new tab opens in the current window and it shows Settings. However, when I minimize all of my windows and press ⌘+,, the Packages menu item flashes and nothing happens:

I can use my cursor to go and select Packages > Settings View > Open (displayed below) and nothing happens then either:

However, if I use my cursor and navigate to Atom > Preferences (displayed below), a new window appears and Settings opens in a new tab.

This leads me to believe that the keybinding entry settings-view:open seems to have priority over application:show-settings, so when there's a conflict, it receieves the shortcut keypress.

Hang in there with me, it gets weirder. Now that I have used my mouse to successfully create a new window with Settings in a tab, I close that window so I only have minimized windows again, and I notice this:

The Packages menu bar item is now missing. I press ⌘+, and this time, the Atom menu item flashes, and I get a new window again with Settings in a new tab!

Also, the Packages menu item is back now:

## Summary of issues observed 1. There is a keybinding conflict for ⌘+,. `settings-view:open` should not have a keyboard shortcut assigned because the macOS system-wide standard is for that shortcut to go to App > Preferences (`application:show-settings` in this case).

If this is fixed/implemented, there will be a problem with no. 3 in my original report at atom/tree-view#690. 2. The Packages menu item should be consistently present or absent when all windows are minimized. As of now, it appears that the logic is set to check for active windows only on close, and not on minimize.

[Ben3eeE]

I don't know what safe mode is in macOS

This refers to Atom safe mode which you achieve by opening Atom with atom --safe from the terminal. This disables all installed community packages to verify that it is a problem with Atom and not one of those. Can you please verify all these points in Atom safe mode and report back :bowing_man:

[jsejcksn]

@Ben3eeE I don't have any Atom shell commands installed and would not like to do that on my macOS installation. Can I launch safe mode another way? The binary is at /Applications/Atom.app/Contents/MacOS/Atom for my install.

[winstliu]

@jsejcksn Application: Open Safe using the command palette (cmd-shift-p).

[jsejcksn]

@50Wliu Thanks for the guidance!

I just tested again and get identical results to my original report.

Also, I've updated to Atom 1.11.1 since the original report so I updated it to reflect that.

/cc @Ben3eeE

[damieng]

Confirmed repro here. Make sure windows are minimized and not closed to get this behavior.

[jsejcksn]

Just posting an update that there's been no change in repro steps or results in 1.27.1.