MacViews: Correct behavior of move and select commands when selection direction changes.

ui/gfx/text_constants.h

Index: ui/gfx/text_constants.h
diff --git a/ui/gfx/text_constants.h b/ui/gfx/text_constants.h
index 93450ea56070d6957379e15733ac24ab14c2d131..1bf48ec05fbacf3b6f295b3660d29a1d86b12eb2 100644
--- a/ui/gfx/text_constants.h
+++ b/ui/gfx/text_constants.h
@@ -15,6 +15,34 @@ enum BreakType {
   LINE_BREAK,          // Stop cursor movement on line ends as shown on screen.
 };
 
+// Specifies how a move and select command behaves if the selection direction
+// is reversed. For example consider the state "ab|cd|e", i.e. cd is selected.
+// Assume the selection direction is from left to right. If we move to the
+// beginning of the line while modifying the selection, the resultant state is:
+// "|ab|cde" for SELECTION_START_NEW, selection direction from right to left.
+// "|abcd|e" for SELECTION_EXTEND, selection direction from right to left.
+// "ab|cde" for SELECTION_CARET.
+enum SelectionReversedBehavior {
+  // Existing selection is deselcted and a new selection is started in the
+  // opposite direction. Default. For example, this is the behavior of
+  // textfields on Mac for the command moveUpAndModifySelection (Shift + Up).
+  // Also this is the default behavior for text editing commands on Linux and
+  // Windows.
+  SELECTION_START_NEW,
+
+  // The existing selection is extended in the opposite direction. For example,
+  // this is the behavior for textfields on Mac for the command
+  // moveToLeftEndOfLineAndModifySelection (Command + Shift + Left).
+  SELECTION_EXTEND,
+
+  // The existing selection reduces to a caret. For example, this is the
+  // behavior for textfields on Mac for the command
+  // moveWordLeftAndModifySelection (Alt + Shift + Left).

[tapted, 2016/05/25 04:31:06]

Is there a rule we can follow for these without having to pass through
SelectionReversedBehavior or the new set of commandIds?

E.g. (somewhat hypothetical - not sure if this will look good) Can we just #if
defined(OS_MACOSX) inside render_text.cc then, instead of passing through
|select_behavior|, pass through |associated_command_id|. Then map a command_id
to its selection behaviour inside render_text.cc

OR (for Mac) could SELECTION_EXTEND be inferred purely from BreakType ==
LINE_BREAK, and SELECTION_CARET be inferred purely from BreakType == WORD_BREAK?
 (if not, would adding a new break type like WORD_OR_CARET_BREAK help?)


This approach may have the benefit of not having to modify ui_strings.grd at
all, which would cancel out some of my other objections :)

[karandeepb, 2016/05/25 05:04:11]

Yes SELECTION_CARET can be inferred from WORD_BREAK, in fact I am doing this
currently. See the #ifdef(OS_MACOSX) I have added to Textfield::ExecuteCommand.
However LINE_BREAK can correspond to all the three different kinds of selection
behaviors on Mac. Blink is able to get around this since it has a mapping for
each of the Mac action messages.

+  SELECTION_CARET,
+
+  SELECTION_DEFAULT = SELECTION_START_NEW,
+};
+
 // Specifies the word wrapping behavior when a word would exceed the available
 // display width. All words that are too wide will be put on a new line, and
 // then: