Fix dodgy states of keyguard transport controls

If a layout has already been requested when we want to show the
correct widget pane, post the event for later and immediately return.

This works because PagedView has some interesting ideas about
maintaining a consistent state. It will attempt to recalculate the
current page position during measurement, but thanks to a reliance on
this measurement to establish scrolling boundaries that scrollTo uses
for clamping plus other code that depends on the idea that it can add
a new widget pane view and immediately scroll to it, this attempt to
scroll fails if the target page was added and measurement is not yet
complete. This patch ensures we don't hit these edge cases in a few
known ways.

While this ends things in the correct state, it predictably has a few
visual artifacts. Situations where things would completely fail
before, positioning pages incorrectly or fading out wrong pages now
will briefly flash and fade the widget frames or in some cases will
visibly animate from the starting page to the correct one. We should
address these issues in a future release.

Bug 11217368
Bug 9760604

Change-Id: I989d03b5bfdd5b6403a6b67a8aae7585ca0c8ae0

0 files changed, 0 insertions, 0 deletions