MacOS shortcut for app switching sometimes focuses desktop instead of fullscreen window

[thoughtarray]

Hi Alacritty team,

I tried my best to find an existing ticket, but perhaps I've the incorrect search terms. This issue seems a lot like #1704.

Issue

If Alacritty is full-screen (MacOS full-screen as in not regular desktop but different space) and when switching between most recent apps using Command-Tab (⌘-Tab) (this is one of the most common hotkey combos in MacOS), Alacritty will sometimes not come into focus. To be more specific, the user view will switch to the normal desktop space and Alacritty will be in the taskbar in "focus", but the Alacritty window will still be in a different space.

It seems to happen pretty randomly too. Sometimes it'll happen seemingly more often than not. I was trying to record a video of the behavior and it seemed to want to function as expected. When I'm working, seems to happen 1 out of 4 switches.

System

OS: MacOS 10.15.4
Version: 0.4.2 (dmg downloaded from Github release based on f68de37)

Logs

Don't know how to get these since it wasn't a CLI download/package. Would love to assist in any way with advice.

[casperstorm]

Alacritty will sometimes not come into focus.

Technically it actually seems like macOS thinks Alacritty is focus the point you ended up on the desktop, judging by the menu bar. This is a bug i've never seen before. Does it only occur when you have it full-screened (different space)?

[thoughtarray]

@casperstorm It seems to always focus alright when I have it on the default desktop space as a windowed app. As far as I know, it only happens when it's as a full-screen space.

Also worth noting, on MacOS, when an app is full-screen (most any app you can go to View -> Enter Full Screen), when in that space, you can put your mouse your mouse to the top of the screen and the menubar will pop down allowing you do access the menu items and buttons. Alacritty doesn't do this. The only two ways to get it out of full-screen mode is to open up mission control, hover over the Alacritty space, and click the un-full-screen button that pops up or to use the hotkeys. This isn't an issue for me per se, but it probably detracts from the uniformity of other apps on MacOS.

[chrisduerr]

It might be interesting to see if this can be reproduced with the examples of winit. There's a fullscreen example that can be executed with cargo run --example fullscreen.

[thoughtarray]

@chrisduerr I tried doing this for y'all. I don't know anything about the Rust ecosystem, but I stumbled around enough to clone winit and run the command you gave. I get an error note: ld: framework not found CoreGraphics. I searched around the READMEs and code but saw no helpful mention of this CoreGraphics thing. I assume it is something that is just known by contributers? Perhaps an OS-level dependency?

[chrisduerr]

I assume it is something that is just known by contributers?

I've never heard of this. Do you get the same error when trying to cargo run Alacritty?

[thoughtarray]

Same error. Here's some output (cleaned up a bit):

Caused by:
  process didn't exit successfully:

rustc \
--crate-name alacritty \
--edition=2018 alacritty/src/main.rs \
--error-format=json \
--json=diagnostic-rendered-ansi \
--crate-type bin \
--emit=dep-info,link \
-C debuginfo=2 \
--cfg 'feature="default"' \
--cfg 'feature="wayland"' \
--cfg 'feature="x11"' \
-C metadata=5c482597a9896bb1 \
-C extra-filename=-5c482597a9896bb1 \
--out-dir /Users/kbrown/tmp/alacritty/target/debug/deps \
-C incremental=/Users/kbrown/tmp/alacritty/target/debug/incremental \
-L dependency=/Users/kbrown/tmp/alacritty/target/debug/deps \
--extern alacritty_terminal=/Users/kbrown/tmp/alacritty/target/debug/deps/libalacritty_terminal-d43b38dc4ce8b7df.rlib \
--extern clap=/Users/kbrown/tmp/alacritty/target/debug/deps/libclap-695fad0b59cdd359.rlib \
--extern dirs=/Users/kbrown/tmp/alacritty/target/debug/deps/libdirs-15a78d292a8960c9.rlib \
--extern env_logger=/Users/kbrown/tmp/alacritty/target/debug/deps/libenv_logger-67dc4c569c8b1e69.rlib \
--extern fnv=/Users/kbrown/tmp/alacritty/target/debug/deps/libfnv-99a8a8d30606ff86.rlib \
--extern font=/Users/kbrown/tmp/alacritty/target/debug/deps/libfont-13ed01a8e6308bb2.rlib \
--extern glutin=/Users/kbrown/tmp/alacritty/target/debug/deps/libglutin-c7f39d3eca378c65.rlib \
--extern libc=/Users/kbrown/tmp/alacritty/target/debug/deps/liblibc-daa466737cfb9a4d.rlib \
--extern log=/Users/kbrown/tmp/alacritty/target/debug/deps/liblog-1235e960fa38ad0c.rlib \
--extern notify=/Users/kbrown/tmp/alacritty/target/debug/deps/libnotify-2ac20d13eae11480.rlib \
--extern parking_lot=/Users/kbrown/tmp/alacritty/target/debug/deps/libparking_lot-d2698503700d89e0.rlib \
--extern serde=/Users/kbrown/tmp/alacritty/target/debug/deps/libserde-7d7c81809a1c9658.rlib \
--extern serde_json=/Users/kbrown/tmp/alacritty/target/debug/deps/libserde_json-6b1827653355f239.rlib \
--extern serde_yaml=/Users/kbrown/tmp/alacritty/target/debug/deps/libserde_yaml-5900329526680597.rlib \
--extern time=/Users/kbrown/tmp/alacritty/target/debug/deps/libtime-1dc976ad3a407828.rlib \
--extern unicode_width=/Users/kbrown/tmp/alacritty/target/debug/deps/libunicode_width-7d3b853ef5c517e4.rlib \
--extern urlocator=/Users/kbrown/tmp/alacritty/target/debug/deps/liburlocator-7fab20a7ee908f8c.rlib \
--extern xdg=/Users/kbrown/tmp/alacritty/target/debug/deps/libxdg-12d6a1dc268466eb.rlib

(exit code: 1)

[chrisduerr]

@casperstorm Which version of macOS are you running? Have you run into any issues like that yourself.

I personally never had any issues.

[casperstorm]

@casperstorm Which version of macOS are you running? Have you run into any issues like that yourself.

Currently running 10.15.3 and have no problem running winit.

I get an error note: ld: framework not found CoreGraphics

@thoughtarray: do you have CTL installed (xcode-select --install)?

I'll try to investigate the app switching issue later today.

[mliker]

I have been experiencing the issue with ⌘-Tab problem for years with the native MacOS Terminal.app and now with Alacritty since I started using it about a week ago.

@thoughtarray any chance you are using a multiplexer like tmux or gnu screen? I personally have been using GNU Screen in the Terminal app and now in Alacritty

[thoughtarray]

@casperstorm I do not have xcode installed. Perhaps that's the undocumented dependency? I've been using Nix for all my dependencies (vs native & Homebrew) thus far.

@mliker I have been using tmux. I just tested Cmd-Tab app switching like 500 times this morning. It happens a lot more often when running tmux, but it also happened a few times while not running it.

Weirdly enough, it seems to happen much more reliably when Allacritty is in a space to the left of the program that I am hotkey switching to and fro.

Perhaps it's some kind of drawing or related timing issue? If I hotkey switch to Allacritty while it's doing operation X, focus will skip over full-screen window to default desktop space?

[chrisduerr]

If @mliker can reproduce it with Terminal.app, it might be a macOS problem.

You say you cannot reproduce it at all with Terminal.app, correct @thoughtarray?

[thoughtarray]

@chrisduerr I don't usually use Terminal.app, but I'll try it on my system. I'm trying to move from iTerm to Alacritty; so I'll try iTerm as well for this issue.

[thoughtarray]

@chrisduerr @mliker I could not repro with iTerm or Terminal. All three were running tmux.

I issued tree / in Allacritty—it didn't goof switching between programs. It seems to happen when it's more idle.

This is all very nebulous. Perhaps I could capture some kind of detailed logs while doing this? Do I need to download Xcode and clone the Allacritty repo to do this?

[chrisduerr]

You can get logs from Alacritty without compiling it manually using alacritty -vvv or alacritty --print-events, but I'm not sure what you'de be looking for.

@mliker Is your issue identical to that described by @thoughtarray? Or is it slightly different?

[mliker]

@chrisduerr I haven't done such a deep analysis as @thoughtarray however the basic description stands. MacOS would end up on the first desktop after cmd-tab switching from another app (in fullscreen) to Alacritty (also in fullscreen) with Alacritty focused in menu bar.

However, as I mentioned this behaviour is not new to me since I have been experiencing the same issue with the Terminal.app for quite some time. I believe it stopped at some point, perhaps two to three major MacOS releases ago but then returned.

I will try to capture the conditions during which this happens.

[thoughtarray]

@chrisduerr I ran alacritty --print-events and didn't get anything that looked helpful. I also finally ran cargo run --example fullscreen inside of winit. It experienced the same issue.

I did notice (and might not have noted before) that it only happens with switching between full-screened spaces & not between programs to and fro the desktop. For example, if Firefox is on the default desktop space, switching to and fro won't display the behavior. But if I full-screen Firefox and do the same, the behavior will happen.

[chrisduerr]

But if I full-screen Firefox and do the same, the behavior will happen.

Have you tried Firefox+Firefox both in fullscreen on different spaces for example?

[thoughtarray]

You can't really do that on MacOS that I know of. You have to switch between programs. If you have one window of a program full-screeened, you can't switch between the two instances.

[quolpr]

I issue the same problem, never happens before with any other apps. Iterm/Kitty/FF/Terminal.app works good.

It has the same happen frequency as with regular use as with tmux.

My guess that it is somehow connected with #3023

[bpinto]

@thoughtarray you should be able to do this. For instance, I run two full-screen instances (separate spaces) of alacrity.

You can create a new window, send it to a different space and then use the shortcut to go to this other space instead of cmd + tab.

https://apple.stackexchange.com/questions/362614/macos-navigating-between-desktops-using-keyboard-shortcuts

P.S.: I also have this focus issue with Alacritty when I switch spaces.

[thoughtarray]

@bpinto I'm familiar with the cmd arrow shortcuts. chrisdurr was asking me to try to repro with a different program with two instances using cmd + tab which you can't do on MacOS (that I know of).

I feel like we've wandered from the original issue. I'm behind at this point though; so I'll download the latest and try again.

[kopiczko]

I have exactly the same issue.

• Alacritty in native full screen.
• Other app in native full screen.
• Cmd+Tab between the two.
• Every second/third switch window doesn't appear. Just the menubar like in the video in the issue description.

I tried with cargo run --example fullscreen (from rust-windowing/winit) with selected borderless fullscreen mode and monitor 0. Can't reproduce.

I'm happy to provide more information.

[stjepangolemac]

I have the same problem, I'm on MacOS 10.15.7.

[raidancampbell]

Another data point, I'm thinking this is coming from winit:

For MacOS 10.15.7:
Winit replication was done via
Glutin replication was done via git clone https://github.com/tomaka/glutin && cd glutin && cargo run --example window

• can reproduce Alacritty native (borderless) fullscreen, single monitor
• can reproduce Winit native (borderless) fullscreen, single monitor
• can reproduce Glutin native (borderless) fullscreen, single monitor
• cannot reproduce Alacritty native (borderless) fullscreen when an external monitor is plugged in
  • tried with both fullscreen spaces on the internal display
  • tried with both fullscreen spaces on the external display
  • tried with both fullscreen spaces on different displays
• cannot reproduce Winit native (borderless) fullscreen when an external monitor is plugged in
  • tried with both fullscreen spaces on the internal display
  • tried with both fullscreen spaces on the external display
  • tried with both fullscreen spaces on different displays
• cannot reproduce Glutin native (borderless) fullscreen when an external monitor is plugged in
  • tried with both fullscreen spaces on the internal display
  • tried with both fullscreen spaces on the external display
  • tried with both fullscreen spaces on different displays

The original report mentions similarity to #1704 (focus lost when switching windows in windowed mode within one space), which I was unable to replicate.

Things I tried and gave up on:

• tracing events via Console.app: not much useful here, but when the issue is replicated MacOS believes it's giving focus to the correct PID. So nothing's likely forking and stealing focus.
• forcing the discrete GPU on: Since plugging in an external display enables the discrete GPU on my laptop, I tried keeping it forced on, and testing. The issue still exists.

Where I'm going from here:

• I've never written a line of Rust, nor MacOS windowing code. Further technical diagnosis is likely beyond me.
• Surprisingly, I didn't find any relevant issues in the winit repository.
• it looks like glutin uses winit for the example (really going out on a limb here, again rust is foreign to me), so I created an issue in winit

[brennantaylor]

I've also been having this issue since 0.5.X was released. Still not resolved in the 0.6.X RC

Indeed alacritty seems to be in focus. My keypresses route to it correctly.

I think it is related to the cmd key getting stuck #3188

I think its related because they issues both appeared at the same time and when switching if I hit Q at the right time I can get alacritty to quit even though I don't have the cmd key pressed and the focus seems wonky.

I've been able to consistently reproduce on multiple macs I've tried. I'm happy to try debugging or provide more details.

I think it may be config related. I just tried testing on a laptop that I have 0.4.X on with the old config so when launching the newer versions to test they bomb and revert to defaults and I cannot reproduce.

[robertdfrench]

I am also running into this on Big Sur (11.0.1, intel) with Alacritty 0.6.0. Thank you @thoughtarray for getting the conversation started, and providing the animation in your original writeup.

For my part, I have seen this happen from time to time with other apps in fullscreen mode, but never really often enough to take notice. It is much more frequent with Alacritty.

I am happy to provide any tracing, logs, etc that may be helpful.

[robertdfrench]

Just noticed this as well, which @brennantaylor has also pointed it out: when this issue occurs, Alacritty does still receive keypresses.

[alexander-somov]

I had the same issue with other Apps. It's gone when I turned off Dock auto-hide and menu bar auto-hide. In the issue description video I see Dock auto-hide enabled too, so it may be related. Hope this could help fix or at least workaround this truly irritating bug.

[JustMikey]

I can confirm that enabling the Automatically hide and show the menu bar checkbox in the General settings makes the cmd-tab switch work as expected.

[stjepangolemac]

I can confirm that enabling the Automatically hide and show the menu bar checkbox in the General settings makes the cmd-tab switch work as expected.

I’m still experiencing the bug regardless of the state of that setting.

[JustMikey]

No, never mind, I imagine I didn't test things properly, the issue remains, my apologies for the confusion.

[thoughtarray]

@casperstorm Can we remove the "A - needs repro" label? Plenty of people are experiencing and reproducing this issue.

[brennantaylor]

I'm starting to suspect it's something to do with alacritty not having any menu items on osx.

Eg in fullscreen I can't get it to expose the menu bar at all. I may try hacking in a noop item and see if the issue disappears. Still happening on 0.7.1 and a fresh catalina laptop. Plugged into an external monitor with desktops mirrored.

[brennantaylor]

For anyone else reading I'm working around the issue by using SimpleFullscreen and just putting alacritty on its own workspace. It kind of sucks but less that cmd-tab going to the wrong workspace.

Fullscreen application switching is still broken in alacritty 0.7.2.

[isra17]

I had an issue where Alacritty would stay focussed when I switch to my Desktop space instead of giving focus back to the application in the Desktop space. After a lot of time spent debugging, I found out that this was caused by my Alacritty.app being assigned to a space... Switching it back to None fixed all my issues:

I don't know if my issue could be related to the issue here.

[moQuez]

The Automatically hide and show the menu bar is actually working out for me

[theherk]

Whether autohide is on or off, my condition is the same. If I just cmd-tab back and forth to the only window I have open, it randomly switches to the app or the desktop over and over. It doesn't seem to have a pattern.