Provide TextInputClients with a way to control virtual keyboard visibility |
||
Issue description
Several TextInputClients don't need Virtual Keyboard at some point.
For example, an invisible textfield in window selector doesn't need VK until it's shown even if it's focused. TextInputClients like it calls KeyboardController::HideKeyboard() directly to prevent VK from showing up. This causes race conditions between calls easily.
It may be reasonable to provide TextInputClients with a standard way to prevent VK from showing up.
To prevent race conditions, that should be declarative like following:
```
class TextInputClient {
...
virtual bool needsVirtualKeyboard() const { return true; }
...
};
```
,
Apr 25 2018
That textfield in the window selector actually needs IME. I'd like to search a window which title is in Japanese. I tried Japanese input on the text field in the window selector and it seems to work well. Another example of this kind of textfields is textfields on ARC++ apps. Android framework allows that hardware keyboard input is started, but not for virtual keyboard state. Technically, InputMethodService#onStartInput is called, but onStartInputView is not called [1]. We have at least two use cases for that. [1]: https://developer.android.com/reference/android/inputmethodservice/InputMethodService.html#onStartInput(android.view.inputmethod.EditorInfo,%20boolean)
,
Apr 25 2018
I see. Thanks for clarification. IMO, TextInputClient should know nothing about VirtualKeyboard. It would be better to let TextInputClient expose necessary information (e.g. IsCaretVisible, GetCaretBounds, etc.) so that the InputMethod::ShowImeIfNeeded() can make better judgement. WDYT?
,
Apr 25 2018
This was also my understanding >TextInputClient should know nothing about VirtualKeyboard. but, the reality is different now. We can find several views calling KeyboardController::HideKeyboard to explicitly hide the keyboard :/ (e.g. search_box_view.cc, browser_app_menu_button.cc, ime_menu_tray.cc (this should be fine), window_selector (please see crrev.com/c/1008525), ARC++ views). > It would be better to let TextInputClient expose necessary information (e.g. IsCaretVisible, GetCaretBounds, etc.) so that the InputMethod::ShowImeIfNeeded() can make better judgement. Yes, if TextInputClient provides enough information, we can make better judgement in ShowImeIfNeeded() or KeyboardController::OnTextInpuStateChanged(). I couldn't come up with better naming for such kind of information so far. In the examples mentioned above except window_selector, caret is still visible after hiding VK, so we couldn't rely on caret information simply. I'll try to find a good condition for this purpose.
,
Sep 11
|
||
►
Sign in to add a comment |
||
Comment 1 by shuchen@chromium.org
, Apr 25 2018