Open s-daveb opened 5 months ago
Debug Output:
EVENT_HANDLER_WINDOW_FOCUSED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
EVENT_HANDLER_WINDOW_MOVED: Safari 5362
It looks like the move event repeats very rapidly. That would explain the window jittering behavior.
How do you move the window? The person in #2211 used BetterTouchTool I think. The built-in yabai way of moving and resizing windows with the cursor works just fine.
There is zero chance that the referenced commit is reverted, because that change alone resolved like 7 different issues that had no reason or logic behind them; implying that there is no other way to resolve those issues.
I move it by clicking on the titlebar and dragging. I only experience the problem when connecting via VNC. I'm only pointing out the commit as a reference - you certainly shouldn't bring back the other bugs!
There might be a solution where you don't have to revert the commit, and I would love to help in any way I can... as of right now, the logs don't seem to be helpful but let me know if you need anything.
For the meantime, I think I will revert my yabai installation and see if that works. The computer experiencing the problem is thankfully, not my main computer, which is why I'm using a remote client.
So I think the problem is as follows:
Yabai needs to intercept mouse-events at the HID-level. This is done using https://developer.apple.com/documentation/coregraphics/1454426-cgeventtapcreate with https://developer.apple.com/documentation/coregraphics/cgeventtaplocation cghidEventTap
.
Your remote administration client synthesizes input events at a higher level; cgSessionEventTap
or cgAnnotatedSessionEventTap
, which makes it so that yabai never sees the mouse-events. This can be confirmed by your log showing only the WINDOW_MOVED
handler being called.
If you do the same while physically using the machine, you should see a preceeding MOUSE_DOWN
entry, followed by interleaved logs (WINDOW_MOVED
, MOUSE_DRAGGED
), ending with MOUSE_UP
.
The reason I don't think this is fixable is that by changing the location to something else than HID, the issues mentioned in the referenced commit returns, and I think this is the only way to detect synthesized input from third-party software.
Debug Output:
EVENT_HANDLER_WINDOW_FOCUSED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362 EVENT_HANDLER_WINDOW_MOVED: Safari 5362
It looks like the move event repeats very rapidly. That would explain the window jittering behavior.
FYI this is exactly what I saw as well.
Hello,
I believe I'm having a problem similar to #2211, which seems to be caused by a recent update, possibly commit 12400 (
fixed bunch of weird macOS cursor quirks
) ...When using macOS's built-in Screen Sharing functionality, I cannot drag or resize any windows with the mouse - I can only do so with the keyboard. (See the video in #2211)
I believe this started around the time when drop zones were implemented, but it could be after that recent commit mentioned in the other issue.Disregard this. I found older commits where it works, and there are drop zones.I can provide debug information in a moment, but to recreate it: