search

lwouis / alt-tab-macos

Windows alt-tab on macOS
https://alt-tab-macos.netlify.app
GNU General Public License v3.0
11.02k stars 330 forks source link

After opening AltTab, it seems like the Next Window shortcut is held or pressed a few times without the user doing anything #3117

Closed SamadiPour closed 6 days ago

SamadiPour commented 10 months ago

Describe the bug

Since a few weeks ago, I have been experiencing drifting when the mouse is hovered over an item. It only happens when the mouse is over an item, and not when it's inside or outside of the frame. When I hold down the Command key and press Tab once (push and release instantly), the selector drifts through the items, sometimes until it reaches the mouse and sometimes until it reaches the end. The Mouse hover option under Also select windows using is disabled.

Screenshots / video

https://github.com/lwouis/alt-tab-macos/assets/24422125/44cec264-affb-4058-b880-d87e60a9a14a

Steps to reproduce the bug

Your environment

warrenseine commented 10 months ago

I experience the same issue with the same environment. I reverted to 6.63.0 and the weird behavior is gone.

I suspect this is related to this commit.

lwouis commented 10 months ago

Thank you @warrenseine for sharing this message.

@SamadiPour does v6.63.0 also fix the issue for you?

I don't see how the issue would be related to the commit though.

@SamadiPour on your video, I see some flickering on the right part of AltTab's window. I'm wondering if you are not suffering from #1840. Could you please show the top menubar of your screen, when the issue happens? If there are 2 AltTab icons, that's the source of the issue right there.

SamadiPour commented 10 months ago

@lwouis Just tried v6.63.0, and it seems like I can't see the issue anymore. I will test more to make sure.

Also, flickering might be because of video compression or the recorder. I didn't see any flicker while using it. I also checked the processes and top menubar, and there was only one instance running.

SamadiPour commented 9 months ago

Update: I have not experienced the issue since downgrading to v6.63.0.

ankushagarwal commented 9 months ago

I can confirm that this happens to me as well. I am on the app version 6.64.0. I am on the latest macOS Sonoma version 14.2.1

https://www.loom.com/share/76a2006f084b4b52880ec7a25879958e

ythosa commented 9 months ago

the same problem

esserrge commented 9 months ago

I had this problem on Sonoma 14.2, it does not seem to happen after upgrade to 14.3. Running alttab 6.64.0 on both versions.

agmitron commented 9 months ago

The same here

Warkanlock commented 9 months ago

Same here; it's getting annoying, but I don't want to just throw the issue to maintainers. I'll be happy to contribute if any core maintainer could give me the issue!

lwouis commented 9 months ago

@ankushagarwal from your video, I wonder if this issue is related in any way to the mouse. Can you reproduce the issue without moving the mouse at all, with the mouse outside the AltTab UI?

Same question for @SamadiPour: can you reproduce the issue without having the mouse hover AltTab?

It looks to me like it could be about key repeats, and maybe external keyboards or software keyboard remappers.

warrenseine commented 9 months ago

I do use BetterTouchTool, but only to bind shortcuts.

I use the trackpad and generally don't touch it while alt-tabbing. But it's possible that the cursor is on top of one of the window tile when I alt-tab. I'll monitor.

Also, I'd like to re-iterate that it's very much likely a regression in 6.64. I reverted to 6.63 and didn't have the issue for a week, then I accidently auto-updated back to 0.64 and the bug started again. I re-installed 6.63 once more.

lwouis commented 9 months ago

I'm suspecting that it is not a regression introduced in v6.64. I suspect it because the only code change that could potentially impact is https://github.com/lwouis/alt-tab-macos/commit/3b0194d886fe31813fda6d319d5b743491b61b98, and I can't imagine how it would interact with the use-case here. I may be missing it, but I could also be guessing right, in which case the issue is not about AltTab, but about something with your environments.

Many people have thought AltTab was bugged, and later realized that the root cause was their external keyboard, software remapper, rare keyboard layout, key repeat settings, etc.

In the case that the issue would be a regression from AltTab, it would be important to establish if indeed the mouse position or movement is involved, or if it's purely a keyboard event issue. The code change only deals with keyboard events, which is why I'm suspecting that the mouse may not have anything to do with the behaviors we see on the various videos.

np25071984 commented 9 months ago

I experience the same.

Noticed strange thing about the app switcher window - when there are two apps (Slack and Mictosoft Teams in my case) and the mouse cursor is somewhere around the switcher area, after I pressed app switch combination the switcher window remains on the screen. Having hard time reproducing it yet but it is definitely the thing. Have caught it many times so far. I believe it is relevant to the topic.

micpiatek commented 9 months ago

Can confirm that I was experiencing the same issue on 6.65.0 and reverting back to 6.63.0 fixed it. Whenever I would move my mouse when using AltTab, the selection window would spaz out and be completely unusable until after restarting the app.

Similar issue that was closed here #3168

harshmandan commented 9 months ago

Same problem here.

I couldn't switch windows using alt+tab whenever the mouse was over the switcher UI, even if I did not move the pointer, the switching would glitch out and wouldn't work.

To make it work I have to move the cursor away from the center (to be specific, outside the switcher overlay) and then alt-tab would work fine.

Reverted to v6.63.0, it's working fine now.

RecuencoJones commented 9 months ago

I've been trying 6.63.0 for a couple days and thought it was fixed but apparently it technically isn't, I still get the option drifting but way less often than with latest version.

warrenseine commented 9 months ago

Yes, same here. I've reported that it was ok in 6.63.0, but after a few days / weeks, I've noticed the behaviour too.

lwouis commented 9 months ago

It looks like my hypothesis was right then.

The issue is either with some external factor like third-party hardware or software, or it's an AltTab issue with has been here for a while, before v6.63.0.

harshmandan commented 9 months ago

I degraded to 6.63.0 after running into this problem and I posted about it here.

I also wanted to share the video of what I was seeing. So I recorded my screen with the degraded version 6.63.0 working normally, then I installed 6.65.0 but I could not reproduce the behavior I was facing before. It's super weird. It has been only a day and If it returns I'll record and add a video here.

Regarding external factors, I use BetterTouchTool (to map gesture on trackpad to open a link in a new tab) and I do use an external bluetooth keyboard.

So maybe it could be related to something external, 🤷‍♂️.

lwouis commented 9 months ago

Can anyone reproduce the issue without having the mouse hover the UI? I would like to understand if the issue is related to the mouse hovering the UI, or not.

broegaard commented 9 months ago

I have also experienced something similar to this problem randomly through months (maybe years), but not with 6.65.0.

I have a gut feeling that it might have something to do with cpu load, but I cannot reproduce it.

warrenseine commented 9 months ago

Can anyone reproduce the issue without having the mouse hover the UI?

I wouldn't be able to say. When it happens, I generally don't know where my cursor was. I'll try to be more attentive.

I have a gut feeling that it might have something to do with cpu load

OMG yes.

Just run yes > /dev/null & yes > /dev/null & yes > /dev/null & yes > /dev/null & (from this decade-old article) and you'll immediately reproduce!

lwouis commented 9 months ago

Hi,

I tried the yes > /dev/null & yes > /dev/null & yes > /dev/null & yes > /dev/null & command to stress the CPU. My AltTab works correctly. No drift in the selected preview.

@warrenseine so you reproduce it consistently with the following command? Do you reproduce this on the macbook internal keyboard, with no software running (e.g. BTT, Karabineer, anything to do with keyboard inputs)?

lwouis commented 9 months ago

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

warrenseine commented 9 months ago

so you reproduce it consistently with the following command?

When I tried, yes. It was quasi-systematic.

Do you reproduce this on the macbook internal keyboard, with no software running (e.g. BTT, Karabineer, anything to do with keyboard inputs)?

I didn't try. I was using an external wireless Logitech keyboard (but I've never had issues with repeated keys) and BTT, Maccy, Rectangle were running. I could try without.

I will first install the custom build and see what happens. I've just installed it and haven't reproduced the bug yet.

Thank you so much for investigating this with us!

SamadiPour commented 9 months ago

Update 2: I have been using v6.65.0 with macOS 14.3 for 1.5 weeks, and I haven't experienced this issue again. I haven't installed/removed any softwares since I opened this issue.

Joeyn1993 commented 9 months ago

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

  • When you hold a key, it repeats. For example, holding a will send a once, then after a kick delay, it will send a on repeat
  • This is true of individual keys, but not shortcuts. When you hit command+c and hold both keys, it doesn't repeat.
  • Furthermore, modifiers keys such as shift, don't repeat either.
  • In order to provide a good experience for AltTab users, we add a layer of custom behavior on top of native key repeats. The goal is to have the user hold command+tab or alt+tab, and the tab key repeats. If they change the key to alt+a, we should also repeat if they hold a. There are many more cases that I won't detail here to avoid confusion.

This has worked brilliantly to resolve the issue - this is my personal expected behaviour.

Are we able to make the difference between this and the standard build as a setting?

RecuencoJones commented 9 months ago

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

  • When you hold a key, it repeats. For example, holding a will send a once, then after a kick delay, it will send a on repeat
  • This is true of individual keys, but not shortcuts. When you hit command+c and hold both keys, it doesn't repeat.
  • Furthermore, modifiers keys such as shift, don't repeat either.
  • In order to provide a good experience for AltTab users, we add a layer of custom behavior on top of native key repeats. The goal is to have the user hold command+tab or alt+tab, and the tab key repeats. If they change the key to alt+a, we should also repeat if they hold a. There are many more cases that I won't detail here to avoid confusion.

This build seems to be fine, I've been trying it with and without stressing CPU and I didn't experience drifting!

warrenseine commented 9 months ago

Yes, I concur. No problem so far with the custom build. And I also agree that I don't have the need for key repetition so an option to turn it off sounds like a good trade-off if we don't get to the bottom of the issue.

lwouis commented 8 months ago

The key repeat code dates from 2020. There was a tweak/improvement in 2022. The fact that people trying the build I shared above report not having the issue suggest that this key-repeat code was the root cause, or at least a catalyst.

This would suggest that the issue is a very old one, which happens on very few setups. I've never been able to reproduce it locally, which makes it very hard to debug.

I'll try looking into the key repeat logic. However, without being able to reproduce locally, it's very theorical work, and I can't confirm if a change works on my own, and will need people to try builds to let me know if it works for them.

I really wonder what is unique about the setup of everyone in this thread, which makes the issue manifest. It seems to be complex setups:

I was using an external wireless Logitech keyboard (but I've never had issues with repeated keys) and BTT, Maccy, Rectangle were running.

Anyone here reproducing the issue on the internal macbook keyboard, with the alt+tab shortcut, and no BTT/Karabineer/remaper turned on?

SamadiPour commented 8 months ago

@lwouis For me, it was with internal macbook keyboard, BTT, and Maccy (not sure if this one is doing anything in this case) On BTT, I only have Command + Shift for changing language and window snapping

lwouis commented 8 months ago

@SamadiPour could you please try with no extra software running to ensure nothing is interfering?

igorpiatkov commented 8 months ago

@lwouis

My setup: MBP16 Intel, latest Sonoma 14.3.1, internal keyboard, karabiner installed but disabled.

👀 Things I observed:

  1. Cursor doesn't play a role in this. I can put it outside the modal and the issue still appears.
  2. Downgrading to v6.63.0 doesn't solve the issue long term.
  3. A simple reinstall of the alt-tab helps for a while then the issue comes back (probably that's why some people say downgrading helped them).
  4. Restarting the alt-tab also helps but not for long.
  5. Sometimes tabs glitch and go back and forth (next-prev-next-prev-next-prev... in place).
  6. Another (important) issue I noticed is that if I move a cursor over a tab it also glitches and the tab starts flashing.

🧠 My thoughts:

  1. Based on the observations above, it might seem like an issue with key repeats but the cursor issue (6) eliminates it.
  2. The "restart" solution means this issue might be related to some kinda of caching, memoization... Which gets reset on quit.
  3. Because of that cursor issue (6) I mentioned above, I don't think "key repeat" is the issue but rather some logic related to any "tab selection" (key/hover). Maybe you can check what exact logic happens on "tab select" and what could cause the issue?
  4. I feel like this whole issue appeared at the same time I noticed the purple menubar icon. I don't think it's related to the menubar icon specifically but I feel it has something to do with that Sonoma release or whatever updates came with it...

I'll keep you posted if I find anything new.

lwouis commented 8 months ago

@igorpiatkov does the issue happen with this build?

Do you have 1 or 2 AltTab icons in the top menubar?

Thank you

igorpiatkov commented 8 months ago

@igorpiatkov does the issue happen with this build?

Do you have 1 or 2 AltTab icons in the top menubar?

Thank you

I'm currently at 6.65.0, it shows 1 AltTab icon in the top menubar. I haven't tested this this build yet. I'll give it a try.

harshmandan commented 8 months ago

Here's a video of the weird behavior:

https://gofile.io/d/JSI8pi

Edit: That was lazy of me to not add any description. So what's happening in the video is not just about mouse hover not working. When trying to quickly switch to the next window (pressing alt+tab), would make the overlay stuck. In the video it's not me holding the (alt+tab) keys to keep the switcher overlay open, it's stuck. At this point, the app does react to the hover events and does not switch to an open app either. To fix it, you need to either press alt+tab again or click to select an application from the stuck overlay.

Edit 2: Another video with POV: https://gofile.io/d/XVJvWr

lwouis commented 8 months ago

@harshmandan on your video, I don't see the behavior described by others in this ticket. I don't see the selected window moving quickly to the right. Instead, it seems you have another issue. It seems that sometimes, AltTab doesn't react to your mouse hovering.

Could you please try this build, and see if it has this issue or not?

Thank you 🙇

harshmandan commented 8 months ago

@lwouis Added description and another video in my last comment.

I have also now switched to the linked build. Will post my experience in a couple of days!

np25071984 commented 8 months ago

Can you reproduce the issue without moving the mouse at all, with the mouse outside the AltTab UI?

@lwouis that is a good point! If I move the cursor away form AltTab UI it works just fine. If my cursor is above when I open AltTab UI up it goes crazy.

Warkanlock commented 8 months ago

I have managed to reduce this problem by changing the window order setting to alphabetical; although it is not the most accurate behavior, for now it works fine and does not drive me crazy when scrolling through tabs.

arya1106 commented 8 months ago

Can you reproduce the issue without moving the mouse at all, with the mouse outside the AltTab UI?

I was able to reproduce this bug reliably until I moved the cursor out of the alt-tab UI as noted above. Not having the cursor in the AltTab UI fixes any skipping problems.

ahmedmahmud commented 8 months ago

Hey, I had a similar issue on both the latest (6.65.0) & on the build posted here.

When the mouse lies in the region of the alt-tab popup to come: Scenario 1:

  1. Hold alt
  2. Double press tab very quickly
  3. Release alt (I usually do this as I release the second tab press) It will open alt tab ui (with mouse over it), switch me one tab, close the ui then open it once more (I have no fingers on my keys at this point) and keep it stuck open

Scenario 2:

  1. Press alt + tab
  2. Press alt + tab again very quickly after the first As if to switch to last tab and back over It will open the ui (with mouse over it) and switch me the expected one tab, but then there is a delay and after about half a second it opens the alt tab ui once more, switches the highlight one over to the next tab but then stays stuck open

I can reproduce both scenarios 100% of the time when my mouse is left in an area over where the alt tab ui opens. I'm not sure if this happens with my mouse outside but I have tried testing it when its outside and can't get anything to happen

lwouis commented 8 months ago

@ahmedmahmud could you please share videos of the 2 scenarios?

Thank you 🙇‍♂️

maximvl commented 8 months ago

Hello I had exactly this issue after updating to 6.64 for a couple of weeks, after reading this thread and installing 6.65 it's fixed completely.

Something I noticed with a 6.64 is that reaction on alt-tab press was not "instant" as it used to be, instead it had a weird lag for switch window to appear and then it would cycle through the list a few times (for me it's usually 3 or 4, but sometimes 7 times if that helps in any way).

I also had only 1 instance running, confirmed via task manager. Hope this helps.

harshmandan commented 8 months ago

@lwouis I'm on the linked build, have not encountered the bug I reported yet. But it seems to be missing a feature. Pressing alt-tab doesn't cycle back to the first window for some reason. Pressing alt-tab only goes in one direction. Here's a video:

https://github.com/lwouis/alt-tab-macos/assets/26344831/d3d930a0-a84c-42b9-bcf6-b17dc849bc59

warrenseine commented 8 months ago

I've now completely quit Alt-Tab and this even happens on the native window switcher 😭 It doesn't repeat, but kinda "freezes".

It correlates with CPU spikes (both on user and system lands):

image

So I'm now pretty sure that Alt-Tab has nothing to do with it. It's just not very resilient to CPU spikes, which is fine because that shouldn't happen in the first place. This would also explain why we don't see the behaviour after disabling key repeats in the custom build. The root cause is still there, but not visible in Alt-Tab anymore.

Next step is to identify if it's another app or a bug in Sonoma because it kinda started with Sonoma, as most have already identified.

maximvl commented 8 months ago

I've now completely quit Alt-Tab and this even happens on the native window switcher

I will keep an eye on it, but for me I was able to reproduce the issue consistently and all I did is install 6.65, close running Alt-Tab, start a new on and it's gone. No other changes, no reboot, no nothing and I haven't seen the issue for a full working day. So maybe there are multiple things going on?

lwouis commented 8 months ago

Using AltTab when the CPU is under heavy load has been discussed here in the past. You may be interested

ahmedmahmud commented 8 months ago

@ahmedmahmud could you please share videos of the 2 scenarios?

Thank you 🙇‍♂️

Sorry for the late reply, I have recorded both scenarios

Scenario 1:

(Keylogger shows opt twice, but it stays held as shown on its "hold" indicator below)

https://github.com/lwouis/alt-tab-macos/assets/19238998/7fadc0b2-1e1e-485d-9f69-9bdc303142d9

Scenario 2:

https://github.com/lwouis/alt-tab-macos/assets/19238998/c7f43e32-4c01-452a-97c6-513017a9f1c1

I hope this is helpful :)

maximvl commented 8 months ago

Yesterday the issue appeared again, first time since 2 weeks (I haven't restarted the os yet). I remember the discussion about high cpu load etc, but my resource usage level is relatively low, so all I did is restarted Alt-Tab and it's all good again. Maybe this helps to find the root cause.