Fix omnibox suggestion: restore selection on WM_IME_ENDCOMPOSITION

chrome/browser/ui/views/omnibox/omnibox_view_win.cc

Index: chrome/browser/ui/views/omnibox/omnibox_view_win.cc
diff --git a/chrome/browser/ui/views/omnibox/omnibox_view_win.cc b/chrome/browser/ui/views/omnibox/omnibox_view_win.cc
index ca7e4c575737eca669711b7c6a025afbb7c9694d..06ffc9528e79fb02bed36c43582a102611f57a57 100644
--- a/chrome/browser/ui/views/omnibox/omnibox_view_win.cc
+++ b/chrome/browser/ui/views/omnibox/omnibox_view_win.cc
@@ -1418,6 +1418,18 @@ LRESULT OmniboxViewWin::OnImeComposition(UINT message,
   return result;
 }
 
+
+LRESULT OmniboxViewWin::OnImeEndComposition(UINT message, WPARAM wparam,
+                                            LPARAM lparam) {
+  // Unlike RichEdit 2.0, RichEdit 4.1 clears the selection when it receives

[Peter Kasting, 2012/10/12 03:29:46]

Nit: Slightly better:

  // The edit control auto-clears the selection on WM_IME_ENDCOMPOSITION, which
  // means any inline autocompletion we were showing will no longer be selected,
  // and therefore no longer replaced by further user typing.  To avoid this we
  // manually restore the original selection after the edit handles the message.

[Seigo Nonaka, 2012/10/12 03:58:07]

Updated, thanks.
On 2012/10/12 03:29:46, Peter Kasting wrote:

+  // WM_IME_ENDCOMPOSITION. Here we need to restore the selection manually.
+  CHARRANGE range;
+  GetSel(range);
+  LRESULT result = DefWindowProc(message, wparam, lparam);
+  SetSel(range);
+  return result;
+}
+
 LRESULT OmniboxViewWin::OnImeNotify(UINT message,
                                     WPARAM wparam,
                                     LPARAM lparam) {