tree 000ca25ec1a0b4015e90c9835ecfb5b2e95ee8ea
parent 82c7794a5fda9805265c8a4b54946ec7968b1e17
author Siarhei Vishniakou <svv@google.com> 1590557983 -0700
committer Siarhei Vishniakou <svv@google.com> 1590692932 -0500

Process focus events first

While refactoring ANR logic, we discovered that an existing Q behaviour
was broken by the focus refactoring. The behaviour aims to prevent keys
from being sent to incorrect windows.

The desired behaviour is as follows: if there are any unfinished events,
then do not process key events (keep them pending), which would allow
these key events to go to a new window, if one becomes focused. The
intent is that if the user hits "Alt+Tab" to switch to another window,
and starts typing right away, we want to make sure that we have
processed the focus event for the new window prior to determining where
to send the new key events after Alt+Tab.

The behaviour is broken today because we put the focus events at the
back of the queue. So even if we process the focus event first, it would
still go to the app after the key event, which would mean that the new
window may receive it, but would drop it because that window does not
yet have focus (since we haven't sent the focused event to it).

The proposed solution is to always put the focus events in the front of
the queue. But, we still need to preserve the relative order of focus
events. To account for that, we put a new focus event always at the
front of the queue, but behind any other focus events that may be there.

Bug: 143459140
Test: added in ANR CL because this behaviour is updated there.
Change-Id: I95256bd3f57988d1990cf1f21267c8f405892e8e