SelectAll when activating the omni box via touch. Regular (short) touch should now work the same wa…

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 982dd7f4ea7ec9b3105d200a0a6adf0473dbb810..88b909fd8876fa365fa9b411fb647cdb6738c719 100644
--- a/chrome/browser/ui/views/omnibox/omnibox_view_win.cc
+++ b/chrome/browser/ui/views/omnibox/omnibox_view_win.cc
@@ -58,6 +58,15 @@
 #include "ui/views/controls/textfield/native_textfield_win.h"
 #include "ui/views/widget/widget.h"
 
+// TODO(tommi): Remove this when we update to a newer SDK.

[Peter Kasting, 2012/05/16 18:30:16]

Just curious: Is there a bug or specific plan on updating to a newer SDK?  It'd
be nice to do that soon so these sorts of blobs don't proliferate.

[tommi (sloooow) - chröme, 2012/05/16 19:11:08]

I don't know if there is a bug filed, but we're already starting to look into
the latest platform sdk (8) so I think that will happen regardless.  Hmm...
maybe I should keep this in the header where there's another similar check, just
to keep the number of blobs down?

[Peter Kasting, 2012/05/16 19:12:34]

That'd be fine.  Whatever you think is best.

I mostly just want to make sure that we don't lose track of any of these blobs,
so they don't live any longer than they have to.

+#ifndef POINTER_MESSAGE_FLAG_FIRSTBUTTON
+#define POINTER_MESSAGE_FLAG_FIRSTBUTTON 0x00000010 // Primary action
+#define IS_POINTER_FLAG_SET_WPARAM(wParam, flag) \
+    (((DWORD)HIWORD(wParam) & (flag)) == (flag))
+#define IS_POINTER_FIRSTBUTTON_WPARAM(wParam) \
+    IS_POINTER_FLAG_SET_WPARAM(wParam, POINTER_MESSAGE_FLAG_FIRSTBUTTON)
+#endif
+
 #pragma comment(lib, "oleacc.lib")  // Needed for accessibility support.
 #pragma comment(lib, "riched20.lib")  // Needed for the richedit control.
 
@@ -1447,6 +1456,12 @@ LRESULT OmniboxViewWin::OnPointerDown(UINT message,
                                       WPARAM wparam,
                                       LPARAM lparam) {
   SetFocus();
+
+  if (IS_POINTER_FIRSTBUTTON_WPARAM(wparam)) {
+    TrackMousePosition(kLeft, CPoint(GET_X_LPARAM(lparam),
+                                     GET_Y_LPARAM(lparam)));
+  }
+
   // ITextInputPanel is not supported on all platforms.  NULL is fine.
   if (keyboard_ != NULL)
     keyboard_->SetInPlaceVisibility(true);
@@ -1663,9 +1678,10 @@ LRESULT OmniboxViewWin::OnMouseActivate(HWND window,
   // reached before OnXButtonDown(), preventing us from detecting this properly
   // there.  Also in those cases, we need to already know in OnSetFocus() that
   // we should not restore the saved selection.
-  if (!model_->has_focus() &&
-      ((mouse_message == WM_LBUTTONDOWN || mouse_message == WM_RBUTTONDOWN)) &&
-      (result == MA_ACTIVATE)) {
+  if (result == MA_ACTIVATE &&

[Peter Kasting, 2012/05/16 18:30:16]

Nit: For consistency with the rest of this file, keep each binary-op expr in
parens.

Any particular reason to reverse the condition ordering?  Both seem about the
same to me.

[tommi (sloooow) - chröme, 2012/05/16 19:11:08]

Done
No reason. They got shifted around while debugging.
I switched them back for a simpler diff.

+      (mouse_message == WM_LBUTTONDOWN || mouse_message == WM_RBUTTONDOWN ||
+       mouse_message == WM_POINTERDOWN) &&
+      !model_->has_focus()) {
     DCHECK(!gaining_focus_.get());
     gaining_focus_.reset(new ScopedFreeze(this, GetTextObjectModel()));
     // NOTE: Despite |mouse_message| being WM_XBUTTONDOWN here, we're not