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.

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

Strange mouse grab on layers with keyboard interactivity #2017

Closed
ettancos opened this issue Apr 10, 2023 · 4 comments · Fixed by #4401
Closed

Strange mouse grab on layers with keyboard interactivity #2017

ettancos opened this issue Apr 10, 2023 · 4 comments · Fixed by #4401
Labels
bug Something isn't working

Comments

@ettancos
Copy link

ettancos commented Apr 10, 2023

I think this is probably a bug, found it testing the eww sys tray elkowar/eww#743 (comment)

there are multiple ways to reproduce, enable :focusable in an eww window or just run any layer-shell example like below with keyboard interactivity

I have follow_mouse = 2

the smithay example is with OnDemand but its same with Exclusive too

git clone https://github.com/Smithay/client-toolkit/
cd client_toolkit 
cargo run --release --example simple_layer

expecatation:
mouse events only go to the layer surface if the cursor is over the surface, if its over another surface events go to that other surface

actual:
mouse events seem to go to the layer surface no matter where i click on the screen

sway: mouse clicks go to the intended target surface, not to the layer if mouse is not over the layer surface
does not happen with kb interactivity disabled

so I'm wondering what might keyboard interactivity have to do with mouse events

@ettancos ettancos added the bug Something isn't working label Apr 10, 2023
@vaxerski
Copy link
Member

Well, not a bug per se, intended to be this way. If a layer requests exclusive focus, we grant it exclusive focus.

@ettancos
Copy link
Author

ettancos commented Apr 10, 2023

have to admit, thats a bit surprising to me, the protocol is not very clear on what normal handling is, but in my interpretation pointer events would be handled as any other surface type

the app that wants focus over the entire screen could just set the exclusive zone that way?

use-cases that I'm used to: click away from launcher if i change my mind, fuzzel, wofi, no way to close them without keyboard
also to close tray menu and such

edit: ignore the exclusive zone thing that was stupid, but just have a transparent surface over the screen is one way to do it if the app wants to

@ettancos ettancos reopened this Apr 10, 2023
@aserowy
Copy link

aserowy commented Dec 29, 2023

Heho,

i think i ran into the same problem (from a somewhat different direction). Im spawning two layer with different sizes:

	Layer level 2 (top):
		Layer 23b2c70: xywh: 3440 0 1200 1920, namespace: eww_dashboard
	Layer level 3 (overlay):
		Layer 2b19ec0: xywh: 3702.5 727 675 466, namespace: rofi

Clicking outside of the rofi namespace does not pass clicks to the eww layer. Is there anything i can do to enable this behavior?

Sidenote: If this is unrelated let me know please. Thus i can remove this comment.

Kind regards
Alexander

@earboxer
Copy link
Contributor

earboxer commented Jan 4, 2024

If a layer requests exclusive focus, we grant it exclusive focus.

I think this is a bug, because layers are requesting exclusive keyboard focus, not exclusive mouse (or touchscreen) focus.

snippet from the spec:

 <entry name="exclusive" value="1">
        <description summary="request exclusive keyboard focus">
          Request exclusive keyboard focus if this surface is above the shell surface layer.

(My use-case is that I want to use a virtual keyboard like wvkbd on a touchscreen device, and opening bemenu makes it impossible to type)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants