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

Smithay doesn't send leave events when surfaces/popups are destroyed #1257

Open
bwidawsk opened this issue Dec 19, 2023 · 1 comment
Open

Smithay doesn't send leave events when surfaces/popups are destroyed #1257

bwidawsk opened this issue Dec 19, 2023 · 1 comment

Comments

@bwidawsk
Copy link
Contributor

While slightly ambiguous, Wayland spec states:

The leave notification is sent before the enter notification for the new focus.

This implies that if a surface had gained focus via wl_pointer::enter and wl_pointer::leave must bookend this before the next enter. It is awkward with the surface being destroyed because there is no longer (potentially) a surface to send the event to. wlroots, and likely other compositors send the event to the NULL surface. Smithay should include this behavior.

This issue was found with a popup in a WLCS test: XdgPopupStable/XdgPopupTest.popup_gives_up_pointer_focus_when_gone/0. The warning triggered is here
bwidawsk added a commit to bwidawsk/smithay that referenced this issue Dec 21, 2023
@bwidawsk
popups: Emit a wl_pointer.leave when destroyed
5704a85 
Wayland protocol indicates that a leave event must be generated before
any subsequent enter event. WLCS (but true in general) have several
tests where a popup is destroyed and it is expected to leave and
re-enter the below surface.

Half of the issue is addressed here, when a popup is explicitly
destroyed the leave event will be generated, though the subsequent enter
will not be generated until there is pointer motion. The enter event can
be simulated within the compositor via a 0 length move event, but the
leave event has no such workaround.

This issue is potentially present for surfaces and subsurfaces as well,
but WLCS doesn't seem to care (that I've yet seen) about those - so
that's deferred until needed.

Fixes Smithay#1257
bwidawsk added a commit to bwidawsk/smithay that referenced this issue Dec 21, 2023
@bwidawsk
popups: Emit a wl_pointer.leave when destroyed
f790409 
Wayland protocol indicates that a leave event must be generated before
any subsequent enter event. WLCS (but true in general) have several
tests where a popup is destroyed and it is expected to leave and
re-enter the below surface.

Half of the issue is addressed here, when a popup is explicitly
destroyed the leave event will be generated, though the subsequent enter
will not be generated until there is pointer motion. The enter event can
be simulated within the compositor via a 0 length move event, but the
leave event has no such workaround.

This issue is potentially present for surfaces and subsurfaces as well,
but WLCS doesn't seem to care (that I've yet seen) about those - so
that's deferred until needed.

Fixes Smithay#1257
bwidawsk added a commit to bwidawsk/smithay that referenced this issue Dec 22, 2023
@bwidawsk
popups: Emit a wl_pointer.leave when destroyed
b72f5e5 
Wayland protocol indicates that a leave event must be generated before
any subsequent enter event. WLCS (but true in general) have several
tests where a popup is destroyed and it is expected to leave and
re-enter the below surface.

Half of the issue is addressed here, when a popup is explicitly
destroyed the leave event will be generated, though the subsequent enter
will not be generated until there is pointer motion. The enter event can
be simulated within the compositor via a 0 length move event, but the
leave event has no such workaround.

This issue is potentially present for surfaces and subsurfaces as well,
but WLCS doesn't seem to care (that I've yet seen) about those - so
that's deferred until needed.

Fixes Smithay#1257
bwidawsk added a commit to bwidawsk/smithay that referenced this issue Jan 3, 2024
@bwidawsk
popups: Emit a wl_pointer.leave when destroyed
8a519a0 
Wayland protocol indicates that a leave event must be generated before
any subsequent enter event. WLCS (but true in general) have several
tests where a popup is destroyed and it is expected to leave and
re-enter the below surface.

Half of the issue is addressed here, when a popup is explicitly
destroyed the leave event will be generated, though the subsequent enter
will not be generated until there is pointer motion. The enter event can
be simulated within the compositor via a 0 length move event, but the
leave event has no such workaround.

This issue is potentially present for surfaces and subsurfaces as well,
but WLCS doesn't seem to care (that I've yet seen) about those - so
that's deferred until needed.

Fixes Smithay#1257
bwidawsk added a commit to bwidawsk/smithay that referenced this issue Jan 3, 2024
@bwidawsk
popups: Emit a wl_pointer.leave when destroyed
12c0cd6 
Wayland protocol indicates that a leave event must be generated before
any subsequent enter event. WLCS (but true in general) have several
tests where a popup is destroyed and it is expected to leave and
re-enter the below surface.

Half of the issue is addressed here, when a popup is explicitly
destroyed the leave event will be generated, though the subsequent enter
will not be generated until there is pointer motion. The enter event can
be simulated within the compositor via a 0 length move event, but the
leave event has no such workaround.

This issue is potentially present for surfaces and subsurfaces as well,
but WLCS doesn't seem to care (that I've yet seen) about those - so
that's deferred until needed.

Fixes Smithay#1257
@Drakulix Drakulix reopened this Jan 7, 2024
@ids1024
Copy link
Member

ids1024 commented May 9, 2024

It seems this is also true for wl_keyboard::leave. And the absence of wl_keyboard::leave events causes XWayland to not release keys that where held when the focused surface was destroyed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bwidawsk @ids1024 @Drakulix