https://codereview.chromium.org/1865063004/

bulk-tagging Phase1 for M52

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

commit ef378f2dcd244781ba68cc2a4f709e6f3d100569
Author: ellyjones <ellyjones@chromium.org>
Date: Mon Apr 18 19:45:38 2016

views: support vertical-drag-to-end on textfields

On Mac, dragging above the top of a textfield drags to the beginning of the
textfield's contents, and dragging below the bottom drags to the end of the
textfield's contents. This change implements that behavior, controlled by
PlatformStyle::kTextfieldDragVerticallyDragsToEnd, which is true only on Mac.

BUG= 600166 

Review URL: https://codereview.chromium.org/1865063004

Cr-Commit-Position: refs/heads/master@{#387988}

[modify] https://crrev.com/ef378f2dcd244781ba68cc2a4f709e6f3d100569/ui/views/controls/textfield/textfield.cc
[modify] https://crrev.com/ef378f2dcd244781ba68cc2a4f709e6f3d100569/ui/views/controls/textfield/textfield_unittest.cc
[modify] https://crrev.com/ef378f2dcd244781ba68cc2a4f709e6f3d100569/ui/views/style/platform_style.cc
[modify] https://crrev.com/ef378f2dcd244781ba68cc2a4f709e6f3d100569/ui/views/style/platform_style.h
[modify] https://crrev.com/ef378f2dcd244781ba68cc2a4f709e6f3d100569/ui/views/style/platform_style_mac.mm

Great!

Reopening this. I don't think the behavior implemented and described in the bug report is entirely as per Cocoa. Whether the text extends to the left or to the right when the mouse goes above or below the textfield is dependent on the start point of the selection.

In a Cocoa textfield, consider text - abcd.

Start selection from left of c and move cursor upwards and slightly to the right while dragging => cd is selected

Start selection from left of c and move cursor upwards and slightly to the left while dragging => ab is selected

Current views behavior => ab is selected in both cases. 

Will look at this as part of  issue 630365 .

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

commit 4e4ca175171eb6c46603799904a624e6797773e4
Author: karandeepb <karandeepb@chromium.org>
Date: Wed Jan 04 02:12:24 2017

RenderTextHarfBuzz: Add support for multi line text selection.

This CL-
  - Adds support for multi-line text selection to RenderTextHarfBuzz. To do this
    RenderTextHarfBuzz::FindCursorPosition and
    RenderTextHarfBuzz::GetSubstringBounds are reimplemented.
  - RenderTextHarfBuzz::FindCursorPosition now returns valid grapheme boundaries
    hence fixing  issue 673986 .
  - RenderTextHarfBuzz::GetSubstringBounds did already support multiline but the
    implementation was flawed. It relied on the text space bounds intersection
    computed from LineSegment's x_range paramater and from TextRunHarfBuzz.
    However these were not in sync if some newline segments were popped or if
    some text was truncated.
  - Enables multi-line text selection for views::Labels.
  - Corrects the behavior for RTL when mouse is dragged above/below the text
    bounds on MacViews.
  - Adds lots of tests.

BUG= 650120 ,  630365 ,  600166 ,  673986 
TEST= Open views_examples_with_content_exe. Select Labels from the dropdown.
Enter a large string in the "Content" textfield. Enable the Multiline and Text
Selection checkboxes. Ensure text selection works correctly on the Label.

Review-Url: https://codereview.chromium.org/2541313002
Cr-Commit-Position: refs/heads/master@{#441290}

[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/gfx/render_text.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/gfx/render_text.h
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/gfx/render_text_harfbuzz.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/gfx/render_text_harfbuzz.h
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/gfx/render_text_unittest.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/controls/label.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/controls/label.h
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/controls/label_unittest.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/controls/textfield/textfield_unittest.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/examples/label_example.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/examples/label_example.h
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/selection_controller.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/style/platform_style.cc
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/style/platform_style.h
[modify] https://crrev.com/4e4ca175171eb6c46603799904a624e6797773e4/ui/views/style/platform_style_mac.mm

Status: Patch in c#11 should fix the RTL behavior related to dragging up and down on a textfield. 
However the behavior in c#9 is still not implemented. However this should not be a P2 and should not block  issue 603386  IMO.

I'm going to leave it as a blocker for Phase3. I prefer not to let this bit of non-conformance to expected behavior slip through.

ellyjones@ - this is the textfield bug I was talking about.

Yah we should fix this :).

The decision to select-to-end should be based on Y-coord, but "which end" to pick should be based on X-coord. (Currently they are both using Y-coord). It should be a straightforward fix.

I felt inspired to fix this today, hope you don't mind :)

https://codereview.chromium.org/2903193003/

Interesting to note that the current MacViews behavior is consistent with single-line textfields in webcontents on Mac, but inconsistent with Cocoa single line textfields.

That CL makes MacViews match Cocoa. Maybe we want to pursue something for textfields in webcontents.. or maybe that will break the web. Anyway, Safari matches Chrome in this regard - maybe it's some web standard.

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

commit 4a1a83be8f109eb727dd9e8724cce49801279faf
Author: tapted <tapted@chromium.org>
Date: Sun May 28 11:08:58 2017

MacViews: Tweak kDragToEndIfOutsideVerticalBounds for single line fields.

Currently the direction to extend is based off the y-position. Dragging
above extends to the logical start and dragging below extends to the
logical end. This matches <textarea> and single-line <input> fields in
webcontents, but does not match single line Cocoa text fields such as
the current Chrome Mac omnibox.

Instead, compare x positions of the selection start and the mouse
cursor. For single line RenderText, extend to the end that is in the
visual direction towards the mouse cursor.

BUG= 600166 

Review-Url: https://codereview.chromium.org/2903193003
Cr-Commit-Position: refs/heads/master@{#475260}

[modify] https://crrev.com/4a1a83be8f109eb727dd9e8724cce49801279faf/ui/gfx/render_text_harfbuzz.cc
[modify] https://crrev.com/4a1a83be8f109eb727dd9e8724cce49801279faf/ui/views/controls/label_unittest.cc
[modify] https://crrev.com/4a1a83be8f109eb727dd9e8724cce49801279faf/ui/views/controls/textfield/textfield_unittest.cc