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 TSF. 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 Bug:1014365 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}
Showing
Please register or sign in to comment