Open 2zqa opened 2 months ago
Reproducible with Zed 0.150.4, Fedora 40, Wayland, Intel HD Graphics 520.
Note that opening another app fixes the issue.
I guess that Gnome sends a keyboard leave event when dragging or resizing, but I'm not sure how other programs/toolkits handle this.
GPUI starts a window move here, and it uses the mouse serial. And the xdg_toplevel::move docs state:
If triggered, the surface will lose the focus of the device (wl_pointer, wl_touch, etc) used for the move.
So it does not really make sense to lose keyboard focus as well.
Note that opening another app fixes the issue.
@ajstarks, what do you mean with this? Could you perhaps create a screencast of this behavior? I cannot reproduce this. Tested with Firefox as a secondary app.
but I'm not sure how other programs/toolkits handle this.
@apricotbucket28 As far as my experience goes, Zed is the only one that does this. Electron apps (like Spotify), native GTK4/libadwaita apps (like the file manager Nautilus) and apps without toolkit (like Blender, although I am not 100% sure if it uses absolutely no gtk)
As far as my experience goes, Zed is the only one that does this. Electron apps (like Spotify), native GTK4/libadwaita apps (like the file manager Nautilus) and apps without toolkit (like Blender, although I am not 100% sure if it uses absolutely no gtk)
I mean like how they handle window focus and decide whether to show the inactive or active title bar color. From the Wayland docs, it does not seem like keyboard focus should be lost when dragging the window. And this issue does not happen on KDE either 😕
Here is a screen cast: the first seconds, you cannot get focus, when I open Chrome, I can. (To reiterate: this is Linux 6.10.6, Fedora 40, Gnome 46, Intel HD Graphics 520) One more data point: I do not see this behavior on my AMD system with the same Desktop Environment
https://github.com/user-attachments/assets/ce208d4b-cb3e-4c84-8e0c-ad9fb22279ac
I don't quite understand your recording. You only moved Zeds window when the secondary program was open. During that window movement, the issue was reproduced: the window lost focus (the taskbar turned transparent; this bug was fixed in #16833). If I understand correctly and you can't unfocus the window unless there is another app open: that should be intended behavior. (Except when moving or resizing the window, that's what this ticket is about)
The recording does not show the cursor, which cannot "connect" with the app window at all upon first opening, so you cannot move it.
On Mon, Sep 2, 2024 at 6:36 PM Marijn @.***> wrote:
I don't quite understand your recording. You only moved Zeds window when the secondary program was open. During that window movement, the issue was reproduced: the window lost focus (the taskbar turned transparent; this bug was fixed in #16833 https://github.com/zed-industries/zed/pull/16833). If I understand correctly and you can't focus, move and resize the window at all when no other app is open, that is a different issue.
— Reply to this email directly, view it on GitHub https://github.com/zed-industries/zed/issues/16484#issuecomment-2325351683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJNXHRTHJP3FOVBEDGCJLZUTR6XAVCNFSM6AAAAABMYJ4WUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVGM2TCNRYGM . You are receiving this because you were mentioned.Message ID: @.***>
That seems to be a separate bug right? Please report as such!
Reported as #17332
Check for existing issues
Describe the bug / provide steps to reproduce it
When resizing or dragging (i.e. window manipulation) Zed, the window loses focus. It should retain focus while doing these operations.
Environment
Zed: v0.148.1 (Zed) OS: Linux Wayland fedora 40 Memory: 31 GiB Architecture: x86_64 GPU: Intel(R) Graphics (RPL-U) || Intel open-source Mesa driver || Mesa 24.1.4
If applicable, add mockups / screenshots to help explain present your vision of the feature
https://github.com/user-attachments/assets/fff24c36-33ce-4d74-8840-58092302a85c
If applicable, attach your Zed.log file to this issue.
No response