This affects regular views texfields (not just omnibox), but only when the cursor is already at the end of the field.

TBH, I think this is an NSTextField bug, but we can try to mimic it.

If I drag down from past-the-end of the text, weird stuff happens when I move the mouse cursor horizontally.

That is, clicking in the Cocoa omnibox and dragging down does _not_ reliably select all the text in it, which I think is the behaviour you're expecting.

Deleted: textfieldbug.mp4 593 KB

	textfieldbug.mp4 593 KB View Download

[Bulk Edit]
Applying M-68 milestone per email discussion with ellyjones@. Pls change it if milestone is incorrectly applied. 

MacViews triage: spqchan@, let's target a fix for this at M-69. Pri-1 since the omnibox is the most used UI surface - even little details like this have to be right.

Yeah - the difference is that RenderText/Textfield use the text-cursor position as the "origin" of the vector that determines select-to-end or select-to-start. However, Cocoa text fields use the mouse-down position as the origin of that same vector.

I think views::Textfield will need to pass through an explicit coordinate to RenderText (i.e. the mouse down). The function RenderText has now that uses the text-cursor position will just pass the text-cursor position coordinate to this function. Or something like that - I haven't tried experimenting yet.

It does feel weird to me to replicate this behavior. For example, single-line text fields in WebContents on Mac do not have this behavior in Chrome or Safari. (Although Safari [and Chrome] WebContents textfields also do not have the relative-to-cursor behaviour, but select to an end based on vertical mouse position only).

But then.... single-line WebContents textfields on *Win/Linux* do not have the *ignore* vertical-mouse-position behaviour that the omnibox has. There are bugs filed for the ignore-mouse-position behaviour on Win/Linux that have been WontFixed.

Anyway, I do think failing to replicate this in the omnibox will be really annoying for Mac users.

+msw in case there are other approaches we should consider.

Removing "Target-68" per comment #4.

over to you tapted :)

tapted: Will you be able to get to this for M69? Thanks!

I don't know why this was bounced to me - I'm pretty swamped in CrOS stuff for m69 (as well as a ton of reviews - I'm not keeping up TBH).

It's probably good for others to become familiar with RenderText anyway.

+robliao@, PTAL comment #14. Thank you.

Staging for now.

Please don't let Chrome Mac ship with this bug. The look and feel of apps is very important to Mac users. Chrome is already foreign-feeling enough - rolling in non-standard behaviors because of switching to an in-house toolkit will make Chrome Mac feel like even more of a hacky port.

Back to status untriaged, so this bug can addressed to an owner. 

Thanks. 

We're currently fine with P2's not having an owner at the moment.

spqchan, can you take this?

The keyboard equivalent of this is  bug 863543 .

Fixed for text fields, so the omnibox may need to pick up something similar.

This is messed up. I tried both dragging directly down and directly up from the omnibox in both Safari and MacViews and I think the behavior is identical - i.e., we correctly imitate Cocoa's bizarre behavior. Specifically, both browsers behave like this:

Cursor at start: bizarre dragging behavior
Cursor at middle: drag up selects to start, drag down selects to end
Cursor at end: bizarre dragging behavior

The specific bizarre stuff is like so: regardless of the vertical direction of the drag, if the drag is towards the "other end" of the text from where the cursor is, the entire text is selected; otherwise nothing is selected.

The behavior difference is that in MacViews, the threshold is the x coordinate of "this end" of the textfield, and in Cocoa, the threshold is the x coordinate that the drag started at, as #5 mentioned. I confirmed that web textfields do not behave this way in Safari or Chrome, but native Cocoa textfields do, so I guess we probably *do* want to match this behavior.

I guess a fix to this will probably lie in RenderTextHarfBuzz::FindCursorPosition().

I think the difference is captured in the comment at #c5.

Basically, when dragging *directly* down the behaviour is erratic, since it depends what side of the 1px vertical line the cursor is.

Cocoa: this line descends down from the mousedown location
Views: this line descends down from the text insertion point location

Retitling to hopefully capture the key usability regression from this.

Punting to M70.

 Issue 898511  has been merged into this issue.

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

commit 47803c371c3a1205d4ad112b357052b17b5965d0
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Fri Jan 04 18:54:43 2019

macviews: support Cocoa drag-to-select behavior

This change implements the Cocoa behavior when dragging outside the vertical
bounds of a textfield. In both platforms, the semantics are as follows:

When continuing a drag that started outside the text, if the drag is on the
leading side of the baseline point, select the entire text backwards from the
trailing end; if the drag is on the trailing side of the baseline point, select
the entire text forwards from the leading end. Note that "forwards" and
"backwards" selection don't exist at all outside of Mac.

The difference is in the baseline point: in Views, the baseline point is the
text insertion cursor, and in Cocoa, it is the location where the running drag
was started.

Bug:  731252 
Change-Id: I61ac6b7d34f0954933486f33e26d228a143eda2f
Reviewed-on: https://chromium-review.googlesource.com/c/1393020
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620019}
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text.cc
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text.h
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text_harfbuzz.cc
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text_harfbuzz.h
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text_mac.h
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/gfx/render_text_mac.mm
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/views/selection_controller.cc
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/views/selection_controller.h
[modify] https://crrev.com/47803c371c3a1205d4ad112b357052b17b5965d0/ui/views/selection_controller_unittest.cc

This is now (finally) fixed on trunk :)