Comment 7 for bug 1292472

Revision history for this message
Robert Carr (robertcarr) wrote :

I propose that this was fixed in r157 onJuly 2nd.

Let's look at how the exception could occur, follow along with grep at home for fun:

Starting with just the mir tree:

1. The exception can only occur in the InputRegistrar::handle_for_channel (android_input_registrar.cpp).
2. handle_for_channel is only invoked from the InputTargetEnumerator and the InputTargeter.

Let's break things down to find the cause of the exception

0. We can see QtMir does not directly use handle_for_channel
1. The InputTargetEnumerator, this is only used by the InputDispatcher. Of course, in qtmir the InputDispatcher is replaced with the QtEventFeeder, so it can not be Mir's usage of the InputTargetEnumerator triggering the exception. We can see the QtMir tree does not directly use the InputTargetEnumerator either, so we can rule it out as the cause of the exception.
2. The InputTargeter is the remaining culprit and its only used by the shell focus setter.

If we dig in to QtMir though we see
1. The InputTargeter is not used directly
2. The shell focus setter is overriden with a noop

By this logic we have shown that handle_for_channel is never called in QtMir (and why would it be? It's purely used to translate between InputDispatcher android types and MirSurfaces to avoid leaking the android input window interface in to the Mir surface interface...as the InputDispatcher is eliminated this code should be as well). However clearly this exception was observed at one point so we must provide an explanation:

bzr blame focussetter.cpp draws our attention to revision 157 (I suggest skimming bzr diff 156..157 as the committ message is a little misleading). We can see prior to r157 QtMir was not overriding the shell focus setter and making use of the default mir impl, thusly making use of the InputTargeter. We can also see application_manager.cpp making direct use of the_focus_controller()->set_focus_to( thus invoking the input targeter. One feasible explanation for the race is that depending on the ordering of observer registration the application manager may be notified surface removal after the input registrar has processed them.

None-the-less I am satisfied that this code path is no longer active and thus closing the bug as fix released.