Views: Draw Textfield selected text in gray when top-level Widget loses focus.

ui/views/controls/textfield/textfield.cc

Index: ui/views/controls/textfield/textfield.cc
diff --git a/ui/views/controls/textfield/textfield.cc b/ui/views/controls/textfield/textfield.cc
index 14736697771bda755ab2e7e08f2ad70cc1fee919..32771b459334186d9f647080cce01ebc6b4d3d27 100644
--- a/ui/views/controls/textfield/textfield.cc
+++ b/ui/views/controls/textfield/textfield.cc
@@ -967,6 +967,12 @@ void Textfield::OnEnabledChanged() {
 }
 
 void Textfield::OnPaint(gfx::Canvas* canvas) {
+  // If the textfield was the last focused view before switching windows, draw
+  // the text selection greyed out.
+  if (!HasFocus() &&
+      GetWidget()->GetFocusManager()->GetStoredFocusView() == this)
+    GetRenderText()->set_draw_unfocused_selection(true);
+
   OnPaintBackground(canvas);
   PaintTextAndCursor(canvas);
   OnPaintBorder(canvas);
@@ -974,6 +980,7 @@ void Textfield::OnPaint(gfx::Canvas* canvas) {
 
 void Textfield::OnFocus() {
   GetRenderText()->set_focused(true);
+  GetRenderText()->set_draw_unfocused_selection(false);
   cursor_visible_ = true;
   SchedulePaint();
   if (GetInputMethod())
@@ -1000,6 +1007,10 @@ void Textfield::OnBlur() {
     cursor_visible_ = false;
     RepaintCursor();
   }
+  // Another focused View in the same Widget means the user is interacting with
+  // something else and the text selection is no longer needed.
+  if (GetWidget()->GetFocusManager()->GetFocusedView())
+    ClearSelection();

[tapted, 2016/09/20 06:57:55]

There are some comments in http://crbug.com/331038 about ClearSelection() here,
including "Not clearing that selection is critically important, it wasn't
changed by accident.  Re-adding that ClearSelection() call will break stuff."
So, I don't think we can take this approach :/

I think we need to feed information about the reason for the focus change into
Textfield. Can we leverage FocusManager::FocusChangeReason?

See void FocusManager::SetFocusedViewWithReason(..) -- we can make Textfield a
FocusChangeListener - it will receive an OnWillChangeFocus message before Blur()
is called and it can save set some flag like
change_selection_background_color_on_next_blur_ if it knows it's about to be
blurerd due to a widget activation change.

Note I'm not sure if FocusChangeReason currently includes "widget *de*activation
-- we may need to add that.

With the `change_selection_background_color_on_next_blur_` approach, OnBlur
would then not call set_focused(false), but instead change the selection
background color on render text -- rendertext wouldn't need changes. OnFocus
would just have to always set the selection background color back to what it
should be.

[Patti Lor, 2016/10/12 05:53:00]

I don't think we need to change FocusChangeReason (unless that approach is
preferred), since there's only one FocusManager per Widget (we can check the
newly focused View is nullptr to determine if the Widget was deactivated, which
is what I have in patchset 6). But I think adding a flag to RenderText isn't
avoidable if we don't clear the text selection - there needs to be a way to
distinguish between case B and C below:

A: Textfield focused, draw text selection.
B: Textfield unfocused, Widget focused.
C: Textfield unfocused, Widget unfocused.

Previously this was "draw it when you're focused" but that needs to change to
"draw it when you're focused and when you were the last focused View with
nothing else now focused", so RenderText needs to know focus as well as whether
there is no other focused View in the Widget. The only other way I can think of
to do this is to give it access to FocusManager, which is probably worse than
adding a flag.

As for the bug you linked, I ended up using the RenderText flag we were trying
to avoid to just mark whether the text selection should be drawn at all times
(not just when unfocused). Clearing the selection inside OnMousePressed() as per
https://bugs.chromium.org/p/chromium/issues/detail?id=331038#c7 doesn't work
because the RenderText/SelectionModel needs to have access to the selection to
work out whether middle click should replace the existing selection and if
greyed out text should be draggable (they use calls to
GetRenderText()->IsPointInSelection()).

 
   DestroyTouchSelection();