We aim to fix the poor interaction between Chrome’s omnibox and the IME (Input Method Editor). The main problem is that IME windows overlap with the omnibox autocomplete results, as pictured below.
This looks unpolished and may be confusing and frustrating to the user.
Our proposal is to close the omnibox autocomplete popup window whenever the IME candidate window is open.
We can easily detect the candidate window on Windows and Chrome OS, so we will implement this design on those platforms. It is likely not possible on Mac and Linux.
After this design is implemented, we can consider a more sophisticated one. We would most likely experiment on Chrome OS, as we have the most control on that platform. If we implement and enjoy very good reception, we can consider further effort to implement on other platforms.
Based on its current input, the omnibox pops up autocomplete results, suggestions that may come from browsing history, bookmarks, or Instant Suggest. There is also inline autocomplete, which is an autocomplete result inserted into the text edit area itself. Inline autocomplete seems to be already disabled during IME composition as it would otherwise interfere with composition (see http://crbug.com/64983 and http://crbug.com/75651).
An IME is used to input text in a more complex manner than the typical direct mapping of keystrokes to characters. For instance, Japanese has too many characters to fit on a keyboard. Using a Japanese IME, the user inputs a reading (“fujisan”) then converts them to the desired characters (“富士山”). The IME presents conversion candidates in a window and in general can present arbitrary UI elements that the application process has little control over.
Text that has been generated through the IME but not yet committed is called composition text (or pre-edit text).
In Chrome as of M15, the IME’s UI elements are drawn over the omnibox autocomplete results, resulting in a poor user experience. Specific issues include the following:
Ideally, we would fix the current poor interaction on all platforms, but our solution is likely implementable only on Windows and Chrome OS.
We would also prefer the solution to work for all IMEs and all languages. However, universal coverage is not an absolute requirement, and we can keep a solution that works for a large enough group of users and doesn’t introduce new problems to others.
If we attempt a more sophisticated design, we would probably implement on Chrome OS first, with an eye to implementing on other platforms if it has good reception. Ideally, we wouldn’t have different behavior on each platform. But it may be the case that only Chrome OS can be saved, due to the control we have on that platform.
We considered several design alternatives. These included the following ideas:
Thus the design and implementation costs are high. If we were to choose one of these solutions, we risk sinking much effort into a solution that might not be usable. Perhaps it would work only for some IMEs or break on future versions of IMEs. Or, it may be implemented and ultimately be poorly received by users.
Another idea is to always close the autocomplete popup during IME composition. However, this is too aggressive. It would prevent users from making use of autocomplete during the input phase before character conversion (for Japanese, when inputting kana before converting to kanji/kana). It would also make little sense for IMEs which usually do not have a composition window open, such as Korean IMEs.
For reference, Firefox and IE9 seem to always close their suggestions popup during IME composition, but we haven’t looked into this extensively.
On Windows, we can detect the candidate window using composition attributes or WM_IME_NOTIFY/IMN_OPENCANDIDATE and IMN_CLOSECANDIDATE messages. When the candidate window is open, we suppress the autocomplete popup. The autocomplete results should be fetched anyway, to be displayed immediately when the candidate window closes.
This only detects the candidate window; some IMEs may display windows other than the candidate window, such as Google Japanese Input, which displays a suggestion window. But we are OK with allowing such popups, as they are not the common case, and removing them might be overly aggressive anyway.
We can also choose whether to enable or disable Instant Search during conversion.
We believe our design is a better UX, but want some way to confirm this. At least, we must confirm that it is it rare that an autocomplete result is used while candidate window is open. Unfortunately, getting UMA metrics like the number of times an autocomplete result was selected is impossible, as Chrome's UI design is such that an item from the dropdown is always selected. We still need ideas for measuring the impact of our change.