Avoid inconsistently showing the VK due to redundant focus changes to TSF

Problem: Input panel policy only gets evaluated when textinputstore acquires
focus. We call AssociateFocus and SetFocus for every focus change that led to
multiple redundant focus messages to TSF. Input panel policy is set to auto
only when the user taps on the edit control. It calls AssociateFocus and
SetFocus instead of just OnStatusChange on the focused textinputstore.
This leads to an inconsistent showing of the virtual keyboard because the
policy switch sometimes happens after the focus gets evaluated by

Solution:When browser launches, address bar is focused and the text input
state is set to URL. The input pane policy is manual on focus. The
text input state change notification calls AssociateFocus which also
calls SetFocus internally on the document manager in TSF. Calling SetFocus
again queues up redundant focus messages in TSF that interferes in other
focus messages so we removed this call in this patch. When user taps on the
address bar, input pane policy is changed to automatic on
ShowVirtualKeyboardIfEnabled call. This notifies TSF with just a status
change of the dynamic flag instead of calling AssociateFocus and SetFocus
(which would have triggered lot of redundant focus messages to TSF.
When the user opens google.com, the script sets focus on the input box
which triggers a DetachTextInputClient from the address bar and also a
text input state change notification. This sets the text input type to be
SEARCH. In between this transition, null TSFtextStore gets focus that also
calls AssociateFocus and TSF transitions its focus from URL to null and then
from null to SEARCH. The input pane policy is set to manual until the user
taps on the search box as we don't want to raise the virtual keyboard on focus
and without user interaction on the page. Once the user taps on the search box,
we set the input pane policy to automatic and call status change to notify
TSF about the change. When TSF calls GetStatus to query for the dynamic flag,
it will have the manual input pane policy disabled and the virtual keyboard
will come up.

Current flow of focus notification to TSF: When text input type is none
i.e. no editable element is in focus, we call AssociateFocus on text input
type and set the input panel policy to manual only when the text input client
is detached or changed. This happens when user switches focus between address
bar and a webpage. We call SetFocus only when the text input type is anything
other than none. We don't call AssociateFocus and SetFocus at the same time
to reduce redundant focus changes that leads to VK issues.

Test: ui\base\ime\win\tsf_input_policy_unittest.cc


Change-Id: I2a2dd28a8ae514cfa4912f5051cde351928b2ab2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1895750
Commit-Queue: Anupam Snigdha <snianu@microsoft.com>
Reviewed-by: Yohei Yukawa <yukawa@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714086}
4 files changed