Page MenuHomePhabricator

Mouse input ignored when sharing screen in MS Teams
Open, Incoming QueuePublic

Description

OS: Fedora 34
E version: 0.24.2 (stock fedora repo)
MS Teams: 1.4.00.26453
Backend: Xorg

I am using MS Teams at work. When sharing my screen in a call, windows do not take any mouse input, i.e. I cannot move windows, cannot click any menus etc.
Keyboard input works as expected.

Of course I first assumed this to be a Teams defect, however trying this out with different window managers it always worked, only in E it does not. Hence this seems to be something the E devs need to take a look into.

mbert created this task.Tue, Nov 9, 3:40 AM
raster added a subscriber: raster.EditedTue, Nov 9, 4:21 AM

https://docs.microsoft.com/en-us/answers/questions/42684/regression-desktop-screensharing-not-working-for-l.html

scroll to the end. i've reported it as best i can to ms as there doesn't seem to be some formal "file a bug" thing for teams

people all over the internet have problems with teams and this overlay window btw - just google for:

teams rect-overlay linux

many wm's and environments are broken with this. what this tool does precisely inside - i don't know but what it ends up doing in xis creating a big window fullscreen with mostly alpha transparency that captures all input from the mouse because it doesn't use window input shapes to limit input. from e's point of view someone created a window with an alpha channel (content is know as it's an RGBA image - e doesn't go inspecting every pixel in the image - that would kill performance and it is not required or even desired in compositing) and that window fulls the screen and wants input on all of the window. teams COULD request input only on some of the window with the x shape extension, but it does not do this, thus the problem.

mbert added a comment.Tue, Nov 9, 4:54 AM

Thank you for this insight. So I "accidentally" picked WMs which happened to work with this. It is indeed very frustrating.

raster added a comment.Tue, Nov 9, 6:10 AM

correct. the above link explains in gory detail what i see on the wm side - no shape input is set. if it intends to do this.. it somehow fails along the way - by the time it gets to the wm end there are no shape input rectangles other than the whole window rect itself. as this rectangle-overlay is a proprietary binary. i guess i could disassemble it and so on but there comes a point where i don't have the time and go "ms - your code, your problem" :)

mbert added a comment.Tue, Nov 9, 6:37 AM

By the way in Window Maker (which used to have problems with it, too) it works.

raster added a comment.Tue, Nov 9, 7:48 AM

well i looked more - and the above is right - e reads the shape and it's not empty.. but i found a problem... e itself MODIFIES the shape input region for the window... it can do this for managed windows but for unmanaged override-redirect .. it should not. it is an e bug where it modifies the shape the client set before e itself then reads back that shape to find it reset... so

raster added a comment.Tue, Nov 9, 7:48 AM

fixed by 662caef9844adbf335a8ae6e47ebc0eacb78692f