nitpicker: apply focus change w/o input events

This patch fixes the corner case where the keyboard focus is defined
independently from user interactivity, e.g., the activation of a
screensaver or lock screen.

In this case, nitpicker would update its internal focus state not before
the next input event is handled. Should this input event be a press
event, this event would wrongly be delivered to the prior focused
session. Another problematic situation is the initial state before the
very first input event occurs. Since the focus remains undefined until
the first input event is handled, an initial key press event would not
be delivered.

This is a regression caused be the transition to the event-session
interface and the removal of the nitpicker's periodic way of operation.
The patch fixes the problem by applying pending focus changes not only
at the input processing but also on the code path that responds to focus
changes (e.g., focus-rom update).

Issue #3812
This commit is contained in:
Norman Feske 2020-09-24 11:51:25 +02:00 committed by Christian Helmuth
parent afab15f1a4
commit 04821b1abc

View File

@ -283,12 +283,9 @@ class Nitpicker::User_state
*/
void focus(View_owner &owner)
{
/*
* The focus change is not applied immediately but deferred to the
* next call of '_apply_pending_focus_change' via the periodic
* call of 'handle_input_events'.
*/
_next_focused = &owner;
_apply_pending_focus_change();
}
void reset_focus() { _next_focused = nullptr; }