Closed choco closed 4 years ago
See my comment in #403 , not sure if related. When mission-control is exited we try and look for changes and reapply regions if necessary - #30
Not sure if this is a bug or a sideeffect of something that was implemented on purpose to solve some other situation.
In my case it is not a crash. Also for me it seems more of a resize/move on the side rather than a resize from the top. Finally it doesn't seem to be related to activating/exiting mission control since it also happens when I w as in the same space by quite some time.
In the weekend I'll try to debug this and maybe provide some video proof ahah
Is this still a thing in the latest version?
I updated to the last version yesterday (it was hard saying goodbye to the borders ahah). I'll let you know at the end of the week if it's still an issue (at least on my end)
Unfortunately it still happens :(
So yabai does not actually respond to move / resize events and try to force the window back to an assigned region etc. like chunkwm did, and so I don't see how this could be caused by yabai as you already confirmed that it is not related to mission-control, which would be the only time we do something that is not a direct response to an event that was generated by macOS.
Could your issue be related to this comment: https://github.com/koekeishiya/yabai/issues/403#issuecomment-635997583 ?
Edit: As you mention in the first post, you're not doing anything when this happens, and so that actually implies that all threads in the yabai process is actually sleeping, waiting for some system event to respond to.
I have the same issue. It seems to happen whenever the mouse hovers over a button which activates a pop-up window.
This happens here as well. I've noticed it happening also when typing in text boxes (even if those text boxes have fixed sizes), but I can't reproduce it deterministically.
For me my window flickers like hell when I hover a link, only on Microsoft Edge
Full screen videos in firefox flicker a lot. It makes fullscreen literally unusable.
I found that this was caused by a rule I put in place to prevent dialogs/popups from appearing behind windows making them un-viewable. After removing this line, the flickering goes away. It's without a doubt caused by Yabai.
yabai -m rule --add app="^(Google Chrome|Code|IntelliJ IDEA)$" manage=on layer=below
The manage=on
property is specifically there to allow applications that are not detected by yabai by default (due to bad accessibility role and subrole assignments from the creator, usually happens to cross platform software that is focused on Linux as the main platform), and is not the inverse of manage=off
which makes yabai treat a window as floating. The way you are using it in the above rule WILL cause bad things to happen.
I found that there were too many applications that had small dialogs or windows that were not resizeable that I wanted the default to be yabai not manage windows and to instead have an allow-list where it only manages a select few windows. After some searching the only solution I found that others use is this combination of manage=off for all apps not in my allow-list and manage=on for those few apps. I'll paste my full configuration below, and if there's a better way to get this behavior please let me know. I've noticed some problems such as borders being incorrectly assigned on new windows of Chrome for example.
Specifically the issues for the flickering seems to be the "layer=below" line. It was the only workaround I could find to prevent dialogs like the floating Calendar app event info pop up from appearing behind managed windows. Found the solution on the issue here based on this comment. For now, that pop up problem has gone away for me even when commenting this line out. Not sure if it's intermittent caused by some other state I'm not currently in.
Here is my yabai configuration:
yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa"
sudo yabai --load-sa
# global settings
yabai -m config \
mouse_follows_focus off \
focus_follows_mouse off \
window_origin_display default \
window_placement second_child \
window_topmost off \
window_shadow off \
window_animation_duration 0.02 \
window_opacity_duration 0.0 \
active_window_opacity 1.0 \
normal_window_opacity 0.85 \
window_opacity on \
insert_feedback_color 0xffd75f5f \
active_window_border_color 0xffc9a8fa \
normal_window_border_color 0xff555555 \
window_border_width 4 \
window_border_radius 12 \
window_border_blur on \
window_border_hidpi on \
window_border on \
split_ratio 0.50 \
split_type auto \
auto_balance off \
top_padding 10 \
bottom_padding 15 \
left_padding 15 \
right_padding 15 \
window_gap 12 \
layout bsp \
mouse_modifier ctrl \
mouse_action1 move \
mouse_action2 resize \
mouse_drop_action swap
# Sets top padding based on whether running on the notched screen or not
yabai -m signal --add event=display_changed action="python3 ~/.config/yabai/set_padding.py"
python3 ~/.config/yabai/set_padding.py
# Applications that are tiled by yabai
applications="(Google Chrome|iTerm2|Code|IntelliJ IDEA)"
yabai -m rule --add app!="^${applications}$" manage=off
# Everything listed gets sent to below layer to prevent
# them from covering floating applications/popup windows
# layer=below causes flickering when hovering over buttons with dialogs though so it's disabled for now
yabai -m rule --add app="^(Google Chrome|Code|IntelliJ IDEA)$" manage=on # layer=below
echo "yabai configuration loaded.."
At the very least change it to the following: yabai -m rule --add app="^(Google Chrome|Code|IntelliJ IDEA)$" role="AXWindow" subrole="AXStandardWindow" manage=on layer=below
The correct way to do this would be to have a rule that says mange=off
for all windows, and then hook a script up to the window_created
signal, calling --toggle float
if the window matches your filter.
At the very least change it to the following:
yabai -m rule --add app="^(Google Chrome|Code|IntelliJ IDEA)$" role="AXWindow" subrole="AXStandardWindow" manage=on layer=below
The correct way to do this would be to have a rule that says
mange=off
for all windows, and then hook a script up to thewindow_created
signal, calling--toggle float
if the window matches your filter.
Can you please elaborate on this? I'm getting the same issue and there doesn't seem to be an easy fix or workaround.
Sometimes when I'm not doing anything I notice that the window flicker, like it was resized and then brought back to the same size. This happens multiple times a day, I have no idea what could be causing this, I also have no idea how to explain this better. I was just wondering if anyone else was experiencing something similar.