[Dev] [wayland] Non-rectangular Wayland window, input-through

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Sat Dec 20 01:17:17 GMT 2014

On Fri, 19 Dec 2014 18:22:16 +0000 "Schaufler, Casey"
<casey.schaufler at intel.com> said:

> Wow. This looks like a security vulnerability. Imagine an app that presents
> itself as a window with lots of pinholes in it. The holes are too small to
> see, and you end up clicking the app behind it unawares of doing so. This
> seems like a *really bad* idea to this humble observer.

i would disagree. there is no targetting here. the app with holes can't know
what's underneath it, so it can't get you to do something specific - eg by
mimicking a fake up on top of your banking app and getting you to let's say
play a game, but n the process accidentally transfer money somewhere - it
doesn't know what is behind so can't do this. in wayland it can't access
buffers of other apps to see their pixels nor can it even know where the other
app surfaces are.

also the user would quickly figure out something is up - as they "click" on the
app on top but nothing happens - as the event went to the app underneath.

also... in a click-to-focus style world... this click going through to the app
underneath would focus it and raise it, the window above losing its above and
focused state. with pointer focus the app on top would have just lost focus
when your mouse/finger goes over a hole. if click-to-raise is enabled here then
the window behind would raise and focus lick click to focus.

on mobile environments there shouldn't be multiple apps stacked anyway - the
foreground app is visible with background apps having been minimized off to
somewhere - there will be nothing underneath the app window.

if an app wants to have some doughnut shaped overlay - it can use subsurfaces
(or can render it itself within its window/surface) and subsurfaces follow
their parent. there might be the rare case that an app wants to overlay stuff
on the screen in general - eg have floating music controls, or facebook uses on
android with chatheads. in these cases the compositor would only allow this if
the app is "allowed" - so it'd have to have some security profile info at some
point. otherwise this feature would be used by the system itself for system
elements overlayed on top of apps (though it depends how you do that - if you
implement such system elements within the compositor, then this feature isn't
needed, and saves running yet another few daemons)

i can go on. :)

but manuel is right - this is a required feature. you want to do dialogs with
rounded corners - if the rounding is round e3nough you want events to go
through to the window underneath. all the bazillion cases of oddly shaped
windows require it too, and it's far from a new or unexpected feature in the ui
world. i would not class this as a security problem as it's really not
something you can easily use to exploit anything useful.

> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Manuel Bachmann
> Sent: Friday, December 19, 2014 8:35 AM
> To: dev at lists.tizen.org
> Subject: [Dev] [wayland] Non-rectangular Wayland window, input-through
> Hi folks,
> It has been asked recently how to make a non-rectangular Wayland window,
> where input events (mouse clicks, touch events) would go "through" the window
> and be received by windows stacked under it - think of a donut where clicking
> in the center passes through. The answer consists in using "wl_region"
> elements together with the "wl_input_region" functions. The idea is to create
> a "wl_region" structure, populate it with several rectangles which will
> determine which parts of the surface are clickable, and then call
> "wl_surface_set_input_region" to make it effective.
> Here is a sample code which demonstrates that :
> http://www.tarnyko.net/repo/wayland-3-shm_surface_input_regions.c
> And a screenshot :
> http://www.tarnyko.net/repo/wayland-3-shm_surface_input_regions.png
> This is a white rectangle with a hole in the center. Clicking in the hole
> will eventually activate other surfaces (here, a "weston-flower" instance).
> --
> Regards,
> Tizen Project

Carsten Haitzler (The Rasterman) <tizen at rasterman.com>

More information about the Dev mailing list