Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ubersicht taking(?) click events on yabai 3.0.2 #535

Closed
arulagrawal opened this issue May 23, 2020 · 11 comments
Closed

Ubersicht taking(?) click events on yabai 3.0.2 #535

arulagrawal opened this issue May 23, 2020 · 11 comments
Labels
help wanted Community help appreciated question Request for information or help, not an issue

Comments

@arulagrawal
Copy link

When using yabai 3.0.2 and Ubersicht 1.4 together and I change workspaces then left click in a window to try and interact with it, that window loses focus, and it seems like text is being selected in my ubersicht bar.

It seems like when I change the workspace with the trackpad gesture this bug occurs but not when I use a keyboard shortcut but I'm not sure about this.

I was pretty sure I had never seen this happen before, and sure enough if I download the 3.0.1 release and just run the pre-built binary this behaviour does not occur.

I've tried to capture this here. You can see discord/spotify losing focus when I left click on them after a workspace change, and text in ubersicht being selected at the top.

@oguzserbetci
Copy link

I'm also having the same problem after upgrading to 3.0.2, I wanted to include some output that I though might be helpful:

thread: 70164480 | event_signal_transmit: transmitting display_changed to 1 subscriber(s)
thread: 70164480 | EVENT_HANDLER_APPLICATION_LAUNCHED: osascript (10640) is not observable, subscribing to activationPolicy changes
thread: 70164480 | EVENT_HANDLER_APPLICATION_TERMINATED: osascript (10640) (not observed)

When I quit uebersicht, I don't get the last two lines, and focussing works as it used to.

@koekeishiya
Copy link
Owner

koekeishiya commented May 23, 2020 via email

@oguzserbetci
Copy link

It happens when I send an event to übersicht to update the active space. And if I remove the events from firing everything is ok. But I didn't change anything in my setup and übersicht except for updating yabai to 3.0.2.

@koekeishiya
Copy link
Owner

koekeishiya commented May 23, 2020

This just seems like a scenario in which 2 bugs have cancelled each other, and when I fixed the bug in yabai, this one surfaces. As you describe, this occurs when ubersicht responds to a signal from yabai that the space has changed. yabai does not do anything here, it is ubersicht that for some reason decides that it needs to steal focus to update, when it should simply refresh in the background.

@arulagrawal
Copy link
Author

Perhaps I should post this issue on the Ubersicht GitHub as well?

@koekeishiya
Copy link
Owner

That's probably the way to go. I don't see how yabai could be causing the issues mentioned here.

@koekeishiya koekeishiya added help wanted Community help appreciated question Request for information or help, not an issue labels May 25, 2020
@AlaaSaadAbdo
Copy link

I'm also facing the same issue

@kule
Copy link

kule commented Jun 5, 2020

Just to add some more information for me this is related to trying to refresh a widget after changing spaces e.g. by using the following in yabairc:

yabai -m signal --add event=space_changed \ action="osascript -e 'tell application id \"tracesOf.Uebersicht\" to refresh widget id \"nibar-spaces-primary-jsx\"'"

With this configured if you ctrl+tab to an app in another space or cmd+tab between apps in different spaces - Ubersicht will steal focus.

Interestingly however if you switch spaces using Yabai instead then everything works as normal e.g. using /usr/local/bin/yabai -m space --focus x.

@koekeishiya
Copy link
Owner

koekeishiya commented Jun 11, 2020

So what is happening is that yabai detects some invisible Übersicht window that fill the entire screen for some reason, concludes that we should not manage said window and make it topmost (due to the setting window_topmost on), because all floating/non-managed windows become topmost when that setting is enabled. This makes it so that the invisible Übersicht window now takes precedence over other windows.

I have resolved this issue by simply blacklisting the Übersicht process from yabai, which makes it so that we no longer attempt to even interact with windows owned by that process. Not sure if this has any downsides to it, but I don't see any other way to fix this.

That said, I do think this is some very weird set up by Übersicht. It is definitely possible to at least not steal click events inside an invisible window, and only allow them to go through in areas where there is an actual widget being drawn.

@koekeishiya koekeishiya added the addressed on master; not released Fixed upstream, but not yet released label Jun 11, 2020
@stoffeastrom
Copy link

I wonder if it's a similar issue I have with using Kap screen recording

Looks like it's using the native screencapture under the hood. After I start recording it's like click events get lost and suddenly it works and stops again.

kap-screenrecording

Using the builtin screencapture works as expected

native-screencapture

I'll stick with the builtin for now :)

@koekeishiya
Copy link
Owner

I changed this from being a specific Übersicht blacklist to not touching properties of windows that report a role of AXUnknown and AXPopover. This does fix the Übersicht issue, and I believe it should handle most of these types of scenarios.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Community help appreciated question Request for information or help, not an issue
Projects
None yet
Development

No branches or pull requests

6 participants