Linking up to our tracking bugs.

To fix this, we probably need to update gfx::

enum VisualCursorDirection {
  CURSOR_LEFT,
  CURSOR_RIGHT
};

with a third option like "CURSOR_UNSPECIFIED", or "CURSOR_MOUSE" or similar. Then tweak RenderTextHarfBuzz::AdjacentCharSelectionModel(..) and methods like GetRunContainingCaret() that support it.

One path could be to make a gfx::SelectionModel effectively have two caret positions. E.g. `size_t SelectionModel::caret_pos()` just returns `selection_.end();` Currently, e.g., when double-clicking a word to select it we are forced to pick a direction for the gfx::Range arbitrarily, but really the direction might not be known until, e.g., AdjacentCharSelectionModel sees a gfx::VisualCursorDirection that attempts to modify the selection.

But I think this (or most parts of it) should be Mac-only. It actually bugs me a little when I select text on Mac by dragging the mouse left-to-right but "go to far" and try pressing shift+left to shrink the selection and the Mac selection style instead expands the selection.

The Mac style does allow other use-cases. E.g. when all the Omnibox text is auto-selected (e.g. Ctrl+L), it's currently impossible to modify either end of the selection bounds -- you can only modify the start of the selection bounds. Although for editing URLs this is more useful since you can more easily trim things off after the hostname, so I don't suggest we deploy this on other platforms either since it could break user's existing workflows.

Do selection ranges on Mac ever assign a direction beyond their first cursor interaction? Perhaps on Mac, RenderText::MoveCursor could optionally reverse the selection range the first interaction after a selection is formed. I sketched an idea below. Or perhaps adding CURSOR_UNKNOWN would help. 

+    bool RenderText::has_directed_selection_ = false;

587  RenderText::MoveCursor... {
+    #if defined(OS_MACOSX)
+      if (!selection().is_empty() && !has_directed_selection_) {
+        if ((direction == CURSOR_RIGHT) == selection().is_reversed())  // TODO: Handle RTL UI
+          SetSelectionModel(/* copy of selection_model_ with a reversed selection range*/);
+        has_directed_selection_ = true;
+      } else if (selection().is_empty()) {
+        has_directed_selection_ = false;
+      }
+    #endif
590    SelectionModel cursor(cursor_position(), selection_model_.caret_affinity());

That should make the appropriate end of the selection range modifiable, and something like that could let us replicate Mac behavior without affecting other platforms. Just an idea, I'm not actively working in this area.

ooh nice - yeah I like that better - it should contain the required changes to a smaller area. I can't think of any situation where the direction could change after the first directed/cursor interaction on Mac (or a case where we'd need a direction before the first a directed interaction).

triage: this bug is still live. Assigning to myself :)

Phase 1 is no more, but these blockers are still interesting. Moving to Phase 2 to track.

Yeah we should fix this. I'm still hacking away at p1s, but I have some brainstate on this. I might steal it if my work queue gets empty, so please move to Started if you start coding (I'll do likewise).

I've started exploring this in https://chromium-review.googlesource.com/#/c/chromium/src/+/700216

macviews triage: tagging this M-64.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e8a67215d1a424861e9fc55d69a2986e61b4be4

commit 0e8a67215d1a424861e9fc55d69a2986e61b4be4
Author: Trent Apted <tapted@chromium.org>
Date: Wed Oct 11 03:07:56 2017

Rename some overloaded "MoveCursorTo()" RenderText methods.

This is to make it clearer which methods may modify a selection
versus replacing it. In preparation for supporting undirected
text selections on Mac.

Bug:  712354 
Change-Id: Ia0750b3670859b563d80fb93ba7d92c948efcc21
Reviewed-on: https://chromium-review.googlesource.com/708076
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507881}
[modify] https://crrev.com/0e8a67215d1a424861e9fc55d69a2986e61b4be4/ui/gfx/render_text.cc
[modify] https://crrev.com/0e8a67215d1a424861e9fc55d69a2986e61b4be4/ui/gfx/render_text.h
[modify] https://crrev.com/0e8a67215d1a424861e9fc55d69a2986e61b4be4/ui/gfx/render_text_unittest.cc
[modify] https://crrev.com/0e8a67215d1a424861e9fc55d69a2986e61b4be4/ui/views/controls/textfield/textfield_model.cc
[modify] https://crrev.com/0e8a67215d1a424861e9fc55d69a2986e61b4be4/ui/views/selection_controller.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ad9e380ab980baefc5572a3e3dd41a1431835976

commit ad9e380ab980baefc5572a3e3dd41a1431835976
Author: Trent Apted <tapted@chromium.org>
Date: Thu Oct 12 02:22:55 2017

Allow undirected selections in gfx::RenderText

On Mac, selecting text with the mouse (regardless of the drag
vector), or with SelectAll, does not give the selection a "direction".
That is, the caret is not known to be at a particular "end" of the
selection. Only with the first directed cursor movement (e.g.
Shift+Right), is the cursor position chosen.

On other platforms, a selection is always directed. (Typically "forward"
but often backwards if the start of a text field should scroll in to
view, or if the mouse drag vector was "backwards").

Implement undirected selections in gfx::RenderText and enable on Mac.

Bug:  712354 
Change-Id: Ib904522db96c84318bb6013f18bf06e16bb3ff8e
Reviewed-on: https://chromium-review.googlesource.com/700216
Reviewed-by: Michael Wasserman <msw@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508225}
[modify] https://crrev.com/ad9e380ab980baefc5572a3e3dd41a1431835976/ui/gfx/render_text.cc
[modify] https://crrev.com/ad9e380ab980baefc5572a3e3dd41a1431835976/ui/gfx/render_text.h
[modify] https://crrev.com/ad9e380ab980baefc5572a3e3dd41a1431835976/ui/gfx/render_text_unittest.cc
[modify] https://crrev.com/ad9e380ab980baefc5572a3e3dd41a1431835976/ui/views/cocoa/bridged_native_widget_unittest.mm
[modify] https://crrev.com/ad9e380ab980baefc5572a3e3dd41a1431835976/ui/views/controls/textfield/textfield_unittest.cc

I just tested this locally and it appears Fixed :)