Exit native fullscreen: no resizing about yabai HOT 27 CLOSED

Fixed on master, hopefully, unless it also varies based on computer specs.

from yabai.

I got confused by your 0 and messed up the spin lock. The latest master works.

from yabai.

Fixed on master. Windows that are fullscreen when we learn about them will no longer be marked as floating.

from yabai.

I'm unable to reproduce this with both Chrome and iTerm. Are you running yabai from the master branch?

from yabai.

Yes, commit id 736c35d

I did some tests by changing my .yabairc. And the Chrome issue only occurs when the border is disabled (yabai -m config window_border off).

from yabai.

The iTerm resizing issue only occurs without a border as well.

window_border on:

# having single iterm2 window, enter native fullscreen using shortcut
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21720
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21695
EVENT_HANDLER_SPACE_CHANGED: 955
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 21720
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695

# leave native fullscreen using shortcut
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21732
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21695
EVENT_HANDLER_SPACE_CHANGED: 761
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 21732
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695

# create new iterm2 window (cmd+n)
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21750
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21750
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21695
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21695
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 21750
EVENT_HANDLER_WINDOW_MOVED: iTerm2 21750
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21750
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21750

window_border off:

# having single iterm2 window, enter native fullscreen using shortcut
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21499
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21569
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21499
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21499
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 21569
EVENT_HANDLER_SPACE_CHANGED: 950
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21499

# leave native fullscreen using shortcut
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21576
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21499
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21499
EVENT_HANDLER_SPACE_CHANGED: 761
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 21576
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21499

# create new iterm2 window (cmd+n)
EVENT_HANDLER_WINDOW_CREATED: iTerm2 21589
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21589
EVENT_HANDLER_WINDOW_MOVED: iTerm2 21589
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 21589
EVENT_HANDLER_WINDOW_RESIZED: iTerm2 21589
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 21589

from yabai.

I still can't reproduce this even with window borders disabled.. weird.

from yabai.

I reproduced this once by accident earlier today and just can't get it to happen again. Such a weird issue. This is so random, it almost feels like it's related to #16 and some (the same?) out-of-order event sequence.

from yabai.

Managed to catch it on video: https://streamable.com/t4gck

I can actually reproduce this reliably with iTerm using background blur and transparency, it definitely seems to be related to lag of some sorts.

This might be similar to opening folders on the desktop, where the Finder window won't get tiled because the animation takes too long.

from yabai.

@koekeishiya I believe this can be fixed by delaying the tiling of windows on the current space until the space attribute of the focused window is non-zero.

# prints old space id
echo "space: $(yabai -m query --windows --window | jq '.space')"

yabai -m window --toggle native-fullscreen

# prints 0, always
echo "space: $(yabai -m query --windows --window | jq '.space')"

sleep 1

# prints new space id
echo "space: $(yabai -m query --windows --window | jq '.space')"

Additionally, yabai -m window --toggle native-fullscreen should not exit until the transition is over.

from yabai.

I believe this can be fixed by delaying the tiling of windows on the current space until the space attribute of the focused window is non-zero.

We try to tile windows when we process a space changed notification that we receive from macOS. I still can't reproduce this problem with any of the applications that I use, so I cannot verify whether the active space we retrieve upon processing that notification is valid or not.

Additionally, yabai -m window --toggle native-fullscreen should not exit until the transition is over.

That is easy to do and should work fine, as while the transition is in progress macOS will report the space id of the fullscreen space, so we just spin lock here.

Edit:

I can actually reproduce this reliably with iTerm using background blur and transparency

I tried this as well, but can't reproduce.

from yabai.

There is a very short period of time (~200ms) after toggling native-fullscreen in any way where these two functions do differ:

# prints 0 during the animation
yabai -m query --windows --window | jq '.space'

# print the "old" space index during the animation
# this might be an invalid index when destroying a fullscreen-space
$(yabai -m query --spaces --space | jq '.index')"

When printing both every 50ms during this animation I get output like this:

while true; do
        echo "space: $(yabai -m query --windows --window | jq '.space') $(yabai -m query --spaces --space | jq '.index')"
        sleep 0.05
done

space: 1 1
space: 1 1
space: 0 1
space: 0 1
space: 0 6
space: 6 6
space: 6 6

I can reproduce this almost 50% of the time just using two Google Chrome windows. This feels like it has gotten worse over the past few weeks, although I cannot point to a specific commit that made things worse. Might just be bias.

Edit:

Video showing the output and the issue, captured on the first attempt: https://streamable.com/etmze

from yabai.

I managed to reproduce the issue by setting full iterm blur, transparency and opening 15+ iterm windows.

When we receive the space changed notification, we retrieve a valid active space. The space is a user space, and I also tried to spinlock on display is animating but that also returns false. The code works as expected.

This is so crazy I don't even want to know how this feature is implemented..

Log:

untiled window 14105
AXWindowResized
AXCreated
AXTitleChanged
AXWindowResized
EVENT_HANDLER_WINDOW_CREATED: iTerm2 14153
activeSpaceDidChangeNotification
AXTitleChanged
AXUIElementDestroyed
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 14153
AXCreated
AXTitleChanged
AXWindowResized
EVENT_HANDLER_WINDOW_CREATED: iTerm2 14159
activeSpaceDidChangeNotification
AXWindowResized
AXWindowMoved
tiled window 14159
AXUIElementDestroyed
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 14159
untiled window 14159
AXWindowResized
AXTitleChanged

Notice how the original window id is 14105 at the time when I initiate window --toggle native-fullscreen to enter native-ffullscreen mode. Then as the transition begins some random weird arbitrary window is created. I assume this has something to do with the animation, as the window is destroyed shortly after. The same happens upon leaving fullscreen mode. Notice how yabai responds to the last space changed notification - verifies that we are indeed in a user space, looks for windows on that space - but tiles and shortly untiles the "fake" iterm window instead, because that is the window that is reported to us, and not our original window 14105.

At this time the last space is not valid, so querying to check if we came from a fullscreen space does not work. The "fake" window reports its fullscreen flag as false, and the display reports that it is not animating.

Edit:

Additionally, yabai -m window --toggle native-fullscreen should not exit until the transition is over.

Tried this and it did not have any impact on the result.

from yabai.

Additionally, yabai -m window --toggle native-fullscreen should not exit until the transition is over.

Tried this and it did not have any impact on the result.

This is just for scripting purposes, because right now when you want to toggle fullscreen for a space and then move it you need to wait until the index changes.

from yabai.

This is just for scripting purposes, because right now when you want to toggle fullscreen for a space and then move it you need to wait until the index changes.

Aight, implemented on master.

from yabai.

Only works for exiting fullscreen right now for me. Here's an easy test:

# prints valid space id when exiting, 0 when entering native-fullscreen
yabai -m window --toggle native-fullscreen && yabai -m query --windows --window | jq '.space'

from yabai.

Right, my bad. Forgot there are two transitions when toggling, should be fixed now.

from yabai.

Still returns 0 for me.

Looks like you're using window_space in the window query I had in my test, which returns index 0, and space_manager_active_space in the newly added code and also in space queries. Could this be key to solving the other issue as well?

What might also be important here is that as toggling native-fullscreen also focuses the window, it is guaranteed to be the focused window during the animation.

from yabai.

Looks like you're using window_space in the window query I had in my test, which returns index 0, and space_manager_active_space in the newly added code and also in space queries. Could this be key to solving the other issue as well?

The space_manager_active_space function tries to locate the focused space by first checking if there is a focused window - if there is we grab the display of that window, and then the visible space off of that display. If there is no focused window, we grab the display that owns the menubar identifier using a private API (this always returns a valid display) and use the space of that display.

The problem with this issue in particular is not that the spaces are messed up, but rather that the application destroys and recreates some window. So when we are notified that the active space is a user space - there is an unknown x amount of time where the application has not yet restored the original window.

The fix would have to be something like "We received a space changed event, did we come here from a fullscreen space, and does that fullscreen space no longer exist - delay our window detection logic by x amount of milliseconds".

Now lets say there is a split-fullscreen space, and only one window is unfullscreened, the space would not be destroyed - so what happens now..

from yabai.

Works for me. Thank you!

from yabai.

Does the resizing work for you doing this:

• have a native-fullscreen window (e.g. Chrome)
• create another new native-fullscreen window using cmd+n
• exit this new native-fullscreen window

from yabai.

Yabai makes a window spawned like that a floating window for whatever reason. Maybe a side effect of #130?

The same issue exists for windows that were already in native-fullscreen when yabai started.

from yabai.

Another negative side effect: I can not open the notification center in fullscreen spaces by swiping from the right edge of the trackpad with two fingers. It just immediately dismisses.

from yabai.

I can not open the notification center in fullscreen spaces by swiping from the right edge of the trackpad with two fingers. It just immediately dismisses.

Tested this just now. Works fine for me on Mojave 10.14.5.

from yabai.

Ah, might then be because I'm just now testing the newest Catalina beta. Will move it over.

Edit: can no longer reproduce after reboot.

from yabai.

There is one more thing that I noticed. I create a new native-fullscreen window using cmd+n like in the example above. Now it sometimes occurs that the mouse focus is not right away on the window. Thus, I need to click the window to gain the mouse focus. Then the yabai process gets a high CPU usage until I switch to another space.

Do you have an idea why this happens?

from yabai.

It doesn't happen anymore with the newest changes :)

from yabai.