Command key on macOS remains activated after window changes (cmd+TAB)

SV3A commented 4 years ago

Since upgrade stable versions from 0.4.0 to 0.4.1 I have experienced that the command key seems to remain in a activated state when changing windows with cmd+TAB.

The result is then either unresponsive keys until cmd is pressed and released again, or when hitting keys like Q or H, the window quits or hides accordingly.

Also, it seems be reproducible consistently when you cmd+TAB to an "empty window" (i.e. on macOS some programs can run without graphical window).

System

OS: macOS Version: alacritty 0.4.1 (4d9253b)

kchibisov commented 4 years ago

Could you, please, provide us the with alacritty --print-events? Oh and press A char right after you've released Cmd, so it'll be easier to track where it happens.

chrisduerr commented 4 years ago

The same issue has been found on Wayland already and we're working with upstream on a fix: https://github.com/rust-windowing/winit/issues/1365

SV3A commented 4 years ago

@kchibisov, here is the output from the moment I make the change to another window and back before lastly pressing Q on its own, which makes Alacritty quit (full output can be seen here).

[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 55, state: Pressed, virtual_keycode: Some(LWin), modifiers: LOGO }, is_synthetic: false } }
[2020-01-11 18:38] [INFO] glutin event: DeviceEvent { device_id: DeviceId(DeviceId), event: ModifiersChanged(LOGO) }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150515250461481 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150515488206557 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: CursorLeft { device_id: DeviceId(DeviceId) } }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150515492133097 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150516908890764 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: Focused(false) }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150516915434996 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150516916802918 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517031654137 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517031815522 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517168091390 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: CursorEntered { device_id: DeviceId(DeviceId) } }
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: CursorMoved { device_id: DeviceId(DeviceId), position: LogicalPosition { x: 698.7109375, y: 135.484375 }, modifiers: (empty) } }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517168767187 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517737398533 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517739167480 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: Focused(true) }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150517757941958 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 12, state: Pressed, virtual_keycode: Some(Q), modifiers: (empty) }, is_synthetic: false } }
[2020-01-11 18:38] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140194742763424)), event: ReceivedCharacter('q') }
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(WaitCancelled { start: Instant { t: 150518580473857 }, requested_resume: None })
[2020-01-11 18:38] [INFO] glutin event: UserEvent(Exit)
[2020-01-11 18:38] [INFO] glutin event: MainEventsCleared
[2020-01-11 18:38] [INFO] glutin event: RedrawEventsCleared
[2020-01-11 18:38] [INFO] glutin event: NewEvents(Poll)
[2020-01-11 18:38] [INFO] glutin event: LoopDestroyed
[2020-01-11 18:38] [INFO] Goodbye
Deleted log file at "/var/folders/mk/k7whcsdn39730rrjs3356z0r0000gn/T/Alacritty-55608.log"

kchibisov commented 4 years ago

So the modifers are correct on chars, however they are absolutely in correct in terms of ModifersChanged event. Since alacritty switched to track events based on information from them, it's just assumes that you have Command Pressed, because there's no event for released mods...

chrisduerr commented 4 years ago

So the modifers are correct on chars, however they are absolutely in correct in terms of ModifersChanged event. Since alacritty switched to track events based on information from them, it's just assumes that you have Command Pressed, because there's no event for released mods...

Yeah, so seems like the upstream issue is correct. It's the same issue as on Wayland.

kchibisov commented 4 years ago

It's the same issue as on Wayland.

On Wayland we have similar issue, not the same issue, since on it our modifiers are always correct, besides one minor case when your app loses keyboard focus and you can't type in it. However the macOS one is more serious, since it actually breaks things for keyboard input, not just some abstract thing, which exists due to a Wayland nature.

rye commented 4 years ago

Just to summarize the discussion from the linked issue (and its counterparts) and make sure I'm understanding correctly, the ModifiersChanged event in winit is not triggered by a "release" of modifiers around entering or leaving a window, since such an event is not fired. So, when you leave Alacritty via Cmd-Tab, that modifier is effectively "stuck," since your window lost focus while a modifier was held down.

Both the macOS and Wayland implementations seem to have used the same assumption.

You can replicate this by Cmd-Tabbing into Alacritty, and typing. The Command key does not seem to be pressed when you do this. But when you Cmd-Tab out of Alacritty and then restore focus to it (by mouse, or whatever) Alacritty behaves as if the Cmd modifier is still pressed from before.

PR rust-windowing/winit#1381 seems to take a promising approach to solving this issue: if modifiers are depressed when either entering or leaving a window, an additional event is emulated; if entering the window, an event is sent with the current modifier state; and if leaving, an event is sent with an empty modifier state to reset the set of modifiers.

The aforementioned PR seems, to me, to only be missing complementary implementations for macOS and Windows.

A patch could be implemented downstream, e.g. here, perhaps by resetting the modifiers field on Processor<N> to ModifiersState::empty() if the window lost focus? If a fix is coming upstream, though, is it better to just wait?

chrisduerr commented 4 years ago

If a fix is coming upstream, though, is it better to just wait?

Indeed.

tantonini commented 4 years ago

Hello, I just would like to mention that the issue is also present on X11

jansol commented 4 years ago

Just wanted to add that clicking on URLs (and losing focus that way) with a modifier key held is also a consistent way to trigger this issue. One that I personally run into a lot.

thamaraiselvam commented 4 years ago

It is really annoying and I did some temporary fix.

Just disabled cmd+m keybinding on Mac Mojave

https://apple.stackexchange.com/a/186510/290655

rye commented 4 years ago

FYI, testing a locally-built alacritty with the following patch to apply (and be compatible with) rust-windowing/winit#1381 fully resolved this issue for me. (Note: once those changes are released, a change like this would be required to maintain compatibility with upstream winit.)

diff --git a/Cargo.toml b/Cargo.toml
index 415ceb9..19d16e9 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -13,3 +13,4 @@ incremental = false

 [patch.crates-io]
 servo-freetype-sys = { path = "servo-freetype-proxy" }
+winit = { git = "https://github.com/murarth/winit", branch = "modifiers-changed-window-event" }
diff --git a/alacritty/src/event.rs b/alacritty/src/event.rs
index bfadbae..1d10463 100644
--- a/alacritty/src/event.rs
+++ b/alacritty/src/event.rs
@@ -585,6 +585,9 @@ impl<N: Notify + OnResize> Processor<N> {
                             processor.ctx.terminal.dirty = true;
                         }
                     },
+                    ModifiersChanged(modifiers) => {
+                        processor.modifiers_input(modifiers);
+                    },
                     KeyboardInput { is_synthetic: true, .. }
                     | TouchpadPressure { .. }
                     | ScaleFactorChanged { .. }
@@ -598,12 +601,7 @@ impl<N: Notify + OnResize> Processor<N> {
                     | Moved(_) => (),
                 }
             },
-            GlutinEvent::DeviceEvent { event, .. } => {
-                use glutin::event::DeviceEvent::*;
-                if let ModifiersChanged(modifiers) = event {
-                    processor.modifiers_input(modifiers);
-                }
-            },
+            GlutinEvent::DeviceEvent { .. } => (),
             GlutinEvent::Suspended { .. }
             | GlutinEvent::NewEvents { .. }
             | GlutinEvent::MainEventsCleared

chrisduerr commented 4 years ago

@tantonini If this is also present on X11, could you open a separate issue for that?

RobertAudi commented 4 years ago

Until this is resolved I started using a less than ideal workaround:

key_bindings:
  # - { key: Key0,      mods: Command,            action: ResetFontSize    }
  # - { key: Equals,    mods: Command,            action: IncreaseFontSize }
  # - { key: Add,       mods: Command,            action: IncreaseFontSize }
  # - { key: Minus,     mods: Command,            action: DecreaseFontSize }
  # - { key: K,         mods: Command,            action: ClearHistory     }
  # - { key: K,         mods: Command,            chars: "\x0c"            }
  # - { key: V,         mods: Command,            action: Paste            }
  # - { key: C,         mods: Command,            action: Copy             }
  # - { key: H,         mods: Command,            action: Hide             }
  # - { key: Q,         mods: Command,            action: Quit             }
  # - { key: W,         mods: Command,            action: Quit             }
  # - { key: F,         mods: Command,            action: ToggleSimpleFullscreen }
  # - { key: Return,    mods: Command,            action: ToggleSimpleFullscreen }
  - { key: Key0,      mods: Command,            action: None }
  - { key: Equals,    mods: Command,            action: None }
  - { key: Add,       mods: Command,            action: None }
  - { key: Minus,     mods: Command,            action: None }
  - { key: K,         mods: Command,            action: None }
  - { key: V,         mods: Command,            action: None }
  - { key: C,         mods: Command,            action: None }
  - { key: H,         mods: Command,            action: None }
  - { key: Q,         mods: Command,            action: None }
  - { key: W,         mods: Command,            action: None }
  - { key: F,         mods: Command,            action: None }
  - { key: Return,    mods: Command,            action: None }

t56k commented 4 years ago

Is building from source the best way to solve for this right now?

kchibisov commented 4 years ago

Yes, this is the only option until the next release. It'll be shortly after winit release with a fix we need to close it. However fix is still under review.

dialtone commented 4 years ago

Obviously the other fix is to go back to 0.4.0 if you can.

kchibisov commented 4 years ago

yeah, that should also work.

t56k commented 4 years ago

Cool, thanks guys

bpinto commented 4 years ago

FYI: Version 0.21.0 of winit has been released.

kchibisov commented 4 years ago

FYI it doesn't have this fix included.

Ps. we depend on winit indirectly through glutin, so there's wasn't any release of it yet, even to get some fixes from v0.21.0.

ipatch commented 4 years ago

Until this is resolved I started using a less than ideal workaround:

key_bindings:
  # - { key: Key0,      mods: Command,            action: ResetFontSize    }
  # - { key: Equals,    mods: Command,            action: IncreaseFontSize }
  # - { key: Add,       mods: Command,            action: IncreaseFontSize }
  # - { key: Minus,     mods: Command,            action: DecreaseFontSize }
  # - { key: K,         mods: Command,            action: ClearHistory     }
  # - { key: K,         mods: Command,            chars: "\x0c"            }
  # - { key: V,         mods: Command,            action: Paste            }
  # - { key: C,         mods: Command,            action: Copy             }
  # - { key: H,         mods: Command,            action: Hide             }
  # - { key: Q,         mods: Command,            action: Quit             }
  # - { key: W,         mods: Command,            action: Quit             }
  # - { key: F,         mods: Command,            action: ToggleSimpleFullscreen }
  # - { key: Return,    mods: Command,            action: ToggleSimpleFullscreen }
  - { key: Key0,      mods: Command,            action: None }
  - { key: Equals,    mods: Command,            action: None }
  - { key: Add,       mods: Command,            action: None }
  - { key: Minus,     mods: Command,            action: None }
  - { key: K,         mods: Command,            action: None }
  - { key: V,         mods: Command,            action: None }
  - { key: C,         mods: Command,            action: None }
  - { key: H,         mods: Command,            action: None }
  - { key: Q,         mods: Command,            action: None }
  - { key: W,         mods: Command,            action: None }
  - { key: F,         mods: Command,            action: None }
  - { key: Return,    mods: Command,            action: None }

can we at the very least keep ⌘c and ⌘v

seems pretty brutal to not have copy paste, or did you map those to another modifier key for the time being?

RobertAudi commented 4 years ago

can we at the very least keep ⌘c and ⌘v

seems pretty brutal to not have copy paste, or did you map those to another modifier key for the time being?

I mostly use vim (and tmux) inside of the terminal and it started to get really annoying to have some "stuff" pasted instead of entering visual mode when pressing ⌘v.

Now keep in mind that I shared my solution as an example – and I'd like to emphasize that I think it's far from ideal. Nothing stops you from keeping some of the key bindings – as a matter of fact I would encourage you to customize you setup to fit your needs 😉

msanders commented 4 years ago

The patch given in the above comment works for me https://github.com/alacritty/alacritty/issues/3188#issuecomment-577369466, built and installed via make app.

OJFord commented 4 years ago

Note that alacritty master now depends on glutin ^0.23, which depends on winit ^0.21, which is newer than the base of the PR that the patch above applies; so cargo disregards it.

tl;dr;fixmyalacritty: Until the winit PR is rebased, Rye's patch (https://github.com/alacritty/alacritty/issues/3188#issuecomment-577369466) should be applied at 6832b86aa7a9adb386394e1caaf373e65297be4e.

kcking commented 4 years ago

when applying that patch at that commit, I first get

error[E0531]: cannot find tuple struct or tuple variant `ModifiersChanged` in this scope
   --> alacritty/src/event.rs:588:21
    |
588 |                     ModifiersChanged(modifiers) => {
    |                     ^^^^^^^^^^^^^^^^ not found in this scope
    |
help: possible candidate is found in another module, you can import it into scope
    |
2   | use glutin::event::DeviceEvent::ModifiersChanged;
    |

then after adding the import it still fails with

error[E0308]: mismatched types
   --> alacritty/src/event.rs:589:21
    |
518 |                 match event {
    |                       ----- this match expression has type `winit::event::WindowEvent<'_>`
...
589 |                     ModifiersChanged(modifiers) => {
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `winit::event::WindowEvent`, found enum `winit::event::DeviceEvent`

Is there a simple fix?

asethwright commented 4 years ago

I was lucky enough to have @kchibisov help me with this on IRC the other day. First, I cloned my own local versions of winit and glutin a directory up from my alacritty directory.

In ../glutin/glutin/Cargo.toml you have to update your winit dependency to the local version In ../winit you have to rebase and apply the patch by @murarth In ./alacritty/Cargo.tml you have to update your glutin dependency to the local version

For winit, you want to rebase master with this commit (effectively merging the PR) https://github.com/rust-windowing/winit/pull/1381.

git clone https://github.com/rust-windowing/winit/ git remote add patch https://github.com/murarth/winit git rebase remotes/patch/modifiers-changed-window-event

Now you've effectively updated the winit version within Glutin, but you still need to apply the patch to Alacritty. I've listd the full patch below...

Alacritty:

--- a/alacritty/Cargo.toml
+++ b/alacritty/Cargo.toml
@@ -18,7 +18,7 @@ fnv = "1"
 serde = { version = "1", features = ["derive"] }
 serde_yaml = "0.8"
 serde_json = "1"
-glutin = { version = "0.23.0", features = ["serde"] }
+glutin = { path = "../../glutin/glutin", features = ["serde"] }
 notify = "4"
 libc = "0.2"
 unicode-width = "0.1"
diff --git a/alacritty/src/event.rs b/alacritty/src/event.rs
index cd4f82a..513a613 100644
--- a/alacritty/src/event.rs
+++ b/alacritty/src/event.rs
@@ -591,6 +591,9 @@ impl<N: Notify + OnResize> Processor<N> {
                             processor.ctx.terminal.dirty = true;
                         }
                     },
+                    ModifiersChanged(modifiers) => {
+                        processor.modifiers_input(modifiers);
+                    },
                     KeyboardInput { is_synthetic: true, .. }
                     | TouchpadPressure { .. }
                     | ScaleFactorChanged { .. }
@@ -604,12 +607,7 @@ impl<N: Notify + OnResize> Processor<N> {
                     | Moved(_) => (),
                 }
             },
-            GlutinEvent::DeviceEvent { event, .. } => {
-                use glutin::event::DeviceEvent::*;
-                if let ModifiersChanged(modifiers) = event {
-                    processor.modifiers_input(modifiers);
-                }
-            },
+            GlutinEvent::DeviceEvent { .. } => (),
             GlutinEvent::Suspended { .. }
             | GlutinEvent::NewEvents { .. }
             | GlutinEvent::MainEventsCleared

Glutin:

--- a/glutin/Cargo.toml
+++ b/glutin/Cargo.toml
@@ -18,7 +18,7 @@ serde = ["winit/serde"]

 [dependencies]
 lazy_static = "1.3"
-winit = "0.21.0"
+winit = { path = "../../winit"  }

 [target.'cfg(target_os = "android")'.dependencies]
 android_glue = "0.2"

Hope this helps someone else! This finally allowed me to be productive again on Mac with Alacritty.

OJFord commented 4 years ago

@kcking See my comment right before yours: https://github.com/alacritty/alacritty/issues/3188#issuecomment-590866212

i.e.

$ git checkout 6832b86aa7a9adb386394e1caaf373e65297be4e
$ git apply rye.patch # copy content from https://github.com/alacritty/alacritty/issues/3188#issuecomment-577369466

That's it.

@asethwright's will give you the latest master patched, if that's important to you, but if it isn't (and ~month old - newer than the released version - is OK) then it's more work than is necessary.

noib3 commented 4 years ago

Is there an ETA on when version 0.4.2 is going to be released?

johnnynia commented 4 years ago

If you're already using Keyboard Maestro a macro like this seems to remedy the issue:

lucazz commented 4 years ago

@johnnynia nice hack! Other ppl that come across this issue from the webz, it works, but it's a paid app. Testing the trial version and hoping this next release w/ a fix comes soon.

khmelevskii commented 4 years ago

Just curious, when you are going to fix this ugly bug? I have a lot of problem with it and I a little bit exhausted to waiting this fix

kchibisov commented 4 years ago

It doesn't directly depend on us. The fix was merged upstream, but they(not alacritty folks) should issue a release in 2 crates (winit + glutin) with it included. If you have a lot of problems, no one stops you from using v0.4.0.

chrisnc commented 4 years ago

Is there something specific that prevented downgrading the winit/glutin dependencies within alacritty until this was fixed (would this even solve the problem)? I assume there is if the blame is being placed on upstream projects for this bug still existing in the latest release, but I don't see a discussion of it on this issue or in the handful of related ones I've looked at. I've switched back to v0.4.0 for now but I can understand other users being annoyed and confused that this was released as a patch version bump and is still currently the default version in Homebrew Casks.

chrisduerr commented 4 years ago

It's already fixed upstream. We're just waiting for them to merge the new version.

It was not anticipated to take this long, but there's no way to know that ahead of time. Downgrading the depedency would also reintroduce all the bugs that existed for the other platforms, so that's not really much of an improvement.

bpinto commented 4 years ago

I don't want to step on anyone's toes, so please bear with me - I also don't have the homebrew knowledge to confirm if my theory would be possible or not.

But for a future similar issue, could we have downgraded the homebrew version since macOS is the only affected environment and then other OS would be running latest version 0.4.1 and macOS 0.4.0?

chrisduerr commented 4 years ago

But for a future similar issue, could we have downgraded the homebrew version since macOS is the only affected environment and then other OS would be running latest version 0.4.1 and macOS 0.4.0?

No, Alacritty does not control anything but the latest master release. If a package should be downgraded or not is not up to Alacritty maintainers at all, but is solely up to the package maintainers.

This has worked just fine on Linux in the past, with maintainers going so far as applying available patches to work around issues. I'd suggest that package maintainers on other platforms do the same.

kchibisov commented 4 years ago

We're not maintaining homebrew package, you should ask them to do that. We do provide images for older releases on release page on github, so you can just grab and use it.

jskswamy commented 4 years ago

@bpinto you could downgrade the alacritty in homebrew by yourself, try the following steps to pin the alacritty to 0.4.0 until fix is released.

# 1. change directory to homebrew cask
$ cd "$(brew --repo homebrew/cask)"

# 2. checkout the to commit which has version 0.4.0
$ git checkout 3e733d8663a6e165d1e648bc166def9328fe2fd8

# 3. unlink the existing alacritty binary
$ brew unlink alacritty

# 4. install version 0.4.0
$ HOMEBREW_NO_AUTO_UPDATE=1 brew install alacritty

# 5. pin alacritty to 0.4.0
$ brew pin alacritty

# 6. go back to homebrew master
$ git checkout master

bpinto commented 4 years ago

@jskswamy thanks for the instructions, it is certainly going to be useful for everyone that finds this thread.

sven-strothoff commented 4 years ago

This might be even easier than @jskswamy solution: You can supply a cask file directly to brew cask install. Just look up the old version on Github and use a direct ("raw") link to the cask file. Simply uninstall alacritty 0.4.1 and run this: brew cask install https://raw.githubusercontent.com/Homebrew/homebrew-cask/a79e2f41df4f9d719fdbdaac2b959e8023c33c85/Casks/alacritty.rb (a79e2f41df4f9d719fdbdaac2b959e8023c33c85 is the commit with 0.4.0) This avoids messing around in Homebrew's repository. When a new version is released you can just install/upgrade the new cask as usual.

VersBinarii commented 4 years ago

Man I thought i was going crazy or that its a case of fatfingerisis. Glad to know its actually a bug. Thanks @sven-strothoff for the workaround

rye commented 4 years ago

Just a heads-up for any users still following this thread who may have switched from Homebrew's casks to the pre-release builds, Alacritty v0.4.2 has since been released and the cask has been updated.

rEnr3n commented 4 years ago

I am on linux using alacritty 0.4.2. I can still reproduce this issue.

nixpulvis commented 4 years ago

@rEnr3n perhaps you're hitting #3466? Either way, you should try the latest master before reporting issues, since things do change as we fix bugs and update dependencies.

alacritty / alacritty

Command key on macOS remains activated after window changes (cmd+TAB) #3188

System