diff options
| author | 2025-02-14 17:56:24 +0100 | |
|---|---|---|
| committer | 2025-02-19 14:24:42 +0100 | |
| commit | c1fe8472c9c2f9b262ce10fff42df6fdce3d8f92 (patch) | |
| tree | 9d616a53a74bc608da042f3d981e800507592e79 /libs/androidfw/ResourceTimer.cpp | |
| parent | 4fb4149e4df534796ded579fae56d4f8cf56118b (diff) | |
Check IME parent visibility for IME window focus
When switching away from an app that has both the IME and the IME dialog
window visible, to an app that previously requested the IME to be
visible, the IME layering target could be updated to the new app before
the input_focus change can take effect. This leads to focus changing to
the IME dialog window, which still exists, but is occluded by the new
app. As this window is not visible, the actual input_focus is set to
null, leaving the IME input target in the previous app. As the IME
surface parent window is computed based on the IME input target, this
will now be not visible.
This changes the logic for checking if an IME dialog window can be
focused from taking into account the IME layering target, to checking
the IME parent. This is only updated in response to input_focus changes,
and represents the current surface the IME container is attached to.
In [1] the existing logic was modified such that the dialog cannot be
focused if either the layering target is not visible, or it did not
request the IME. However, the IME Switcher menu can be shown independent
of the IME being visible, and it wouldn't receive input_focus in this
case anymore, which makes it harder to dismiss. This also removes the
check of the IME being visible for IME dialog windows.
This also unifies the changes with the IME child window branch, which
should also check the IME parent visibility. Lastly, the IME visibility
is better determined from the ImeInsetsSourceProvider rather than the
IME layering target (for RemoteInsetsControlTarget cases).
Note, this adds the IME parent visibility check for all windows that
have mIsImWindow, which includes TYPE_INPUT_METHOD. Normally these
windows fail the canReceiveKeys check above, as they have
FLAG_NOT_FOCUSABLE. Otherwise, these checks also make sense for them.
[1]: Ia5ea318b2a92ccc003f3192a198bf041365f70cf
Flag: EXEMPT bugfix
Test: atest DisplayContentTests#testImeChildWindowFocusWhenImeParentWindowChanges
DisplayContentTests#testImeDialogWindowFocusWhenImeParentWindowChanges
DisplayContentTests#testImeWindowFocusWhenImeParentWindowChanges
Bug: 388732427
Change-Id: I3ac91cf02f0270b2d54581aa9174a875836ca692
Diffstat (limited to 'libs/androidfw/ResourceTimer.cpp')
0 files changed, 0 insertions, 0 deletions