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.

Sign up for GitHub

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

Jump to bottom

Drag & drop doesn't focus target window #5116

Closed
WhyNotHugo opened this issue Mar 17, 2020 · 1 comment · Fixed by #5489
Closed

Drag & drop doesn't focus target window #5116

WhyNotHugo opened this issue Mar 17, 2020 · 1 comment · Fixed by #5489
Labels
bug Not working as intended

Comments

@WhyNotHugo
Copy link
Contributor

When I drag something (eg: an image) between two windows (A->B), once I drop/release, my mouse cursor is hovering on window B, but that window doesn't have focus. I need to move the mouse out and back again.

Oddly though, the source window doesn't seem to have the focus either.

I've verified this by drag-and-dropping...

  • From nemo to telegram.
  • From nemo to firefox.

These are all wayland-native apps.

I'm running sway 1.4.
@Xyene
Copy link
Member

Xyene commented Apr 29, 2020 •
edited

I've been able to reproduce this on sway/wlroots master (currently 99897a6). The window borders change colors as if the window should have focus, but keyboard focus is not passed on drop, and requires re-entering the surface to trigger. The pointer enter event doesn't fire either, until the next mouse movement (but does not require re-entering).

@Xyene Xyene added the bug Not working as intended label Apr 29, 2020
kennylevinsen added a commit to kennylevinsen/sway that referenced this issue Jun 28, 2020
@kennylevinsen
seat: Focus drag target when drag is destroyed
e0501c3 
wlr_drag installs grabs for the full duration of the drag, leading to
the drag target not being focused when the drag ends. This leads to
unexpected focus behavior, especially for the keyboard which requires
toggling focus away and back to set.

We can only fix the focus once the grabs are released, so focus the drag
target when the wlr_drag destroy event is received.

Closes: swaywm#5116
@kennylevinsen kennylevinsen mentioned this issue Jun 28, 2020
Merged
kennylevinsen added a commit to kennylevinsen/sway that referenced this issue Jun 28, 2020
@kennylevinsen
seat: Refocus seat when wlr_drag is destroyed
7ceae3a 
wlr_drag installs grabs for the full duration of the drag, leading to
the drag target not being focused when the drag ends. This leads to
unexpected focus behavior, especially for the keyboard which requires
toggling focus away and back to set.

We can only fix the focus once the grabs are released, so refocus the
seat when the wlr_drag destroy event is received.

Closes: swaywm#5116
emersion pushed a commit that referenced this issue Jun 30, 2020
@kennylevinsen @emersion
seat: Refocus seat when wlr_drag is destroyed
492267a 
wlr_drag installs grabs for the full duration of the drag, leading to
the drag target not being focused when the drag ends. This leads to
unexpected focus behavior, especially for the keyboard which requires
toggling focus away and back to set.

We can only fix the focus once the grabs are released, so refocus the
seat when the wlr_drag destroy event is received.

Closes: #5116
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Not working as intended
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

seat: Refocus seat when wlr_drag is destroyed kennylevinsen/sway
2 participants
@WhyNotHugo @Xyene