mirscreencast steals all key events.

[Brandon Schaefer]

To test:

1) Open up a mir server (i used demo_mir_shell_server)
2) Run a client example (i used demo_mir_client_eglplasma)
3) Run mir screen cast
4) Press 'q' to exit (this is true for the egl examples/demos).

Expected result:
  The demo closes.

Actual Result:
  No key events happen, and demo stays open.

This seems to be caused by mir screen cast stealing the events. To confirm this, simply alt+tab in a demo_mir_server_shell which will bring the demo back into focus. Then a 'q' will exit the progam. (ie. key events work again).

Testing out:
src/server/shell/default_focus_mechanism.cpp

void msh::DefaultFocusMechanism::set_focus_to();

It looks like its coming from the case when deafult_surface() == nullptr. When this happens it clears the input, leaving the demo in limbo without events!

I can confirm thats the case here as commenting out:
input_targeter->focus_cleared();

Fixes the issue, though im not sure what the real fix for this would be.

[Daniel van Vugt (vanvugt)]

Sounds like this might be another form of bug 1400218 where invisible surfaces get given input (and steal from the visibly focused surface).

[Brandon Schaefer (brandontschaefer)]

The mirscreencast doesn't create a surface though :(.

[Daniel van Vugt (vanvugt)]

Oh I see, yes default_surface() == nullptr.

[Brandon Schaefer (brandontschaefer)]

Overall looking at the code, it seems like we should just avoid clearing the input focus (ie. the keyboard focus) if the session does not have a surface? Though im not sure what the clearing of the input foucs was fixing!

[Daniel van Vugt (vanvugt)]

I think you're right. Or that focus should skip apps that don't have surfaces. Also, don't change focus at all if the new app starting has no surfaces.

[Alan Griffiths (alan-griffiths)]

Agreed. Focus is only meaningful for sessions with surfaces.

[Alan Griffiths (alan-griffiths)]

Actually, Focus is only meaningful for sessions with *visible* surfaces.

[Daniel van Vugt (vanvugt)]

That's an interesting statement. Because a new app's surfaces are not "visible" until some time after the app starts (first frame posted).

So either we do have to assign focus to non-visible apps, or our focus-on-open logic needs to become more complicated and defer focus until such time as it's possible :(

[Alan Griffiths (alan-griffiths)]

Yes, it isn't easy. Is "visible for compositing" the same as "visible for input"?

[Daniel van Vugt (vanvugt)]

Sounds like a cookie/timestamp type problem for deciding focus, which is being discussed in bug 1398852.

[Daniel van Vugt (vanvugt)]

Medium till we need screencast in the real world to capture real users using real apps. Then it becomes High :)

[Michał Sawicz (saviq)]

Syncing task from Mir.