Are we sure we want this? Sure it's a change from the existing Cocoa dialog, but I suspect it's a bug that someone forgot to disable selection on the NSControl for the Cocoa dialog.

Safari's ~equivalent dialog (attached) has no selectable text. And elsewhere in Chrome we go to lengths [1] to ensure text is not selectable. And E.g. the Cocoa old-school HTTPAuth dialog in Chrome has no selectable text outside of the text fields (also attached). For that one go to, e.g. apted.net/chat with MacViews webui dialogs *disabled*.

[1] E.g. https://cs.chromium.org/chromium/src/ui/base/cocoa/controls/hyperlink_text_view.mm?q=selectionRangeForProposedRange&sq=package:chromium&l=55

Deleted: Screen Shot 2016-06-06 at 10.02.44 AM.png 53.6 KB

	Screen Shot 2016-06-06 at 10.02.44 AM.png 53.6 KB View Download

Deleted: Screen Shot 2016-06-06 at 10.07.25 AM.png 30.5 KB

	Screen Shot 2016-06-06 at 10.07.25 AM.png 30.5 KB View Download

The text in OS X alert panels is selectable (e.g. the Confirm Navigation alert in Chrome) - I think the fact that Safari's text is not selectable in that alert is not a bug per se, but it's not what you want.

Selectable text in alerts is useful when users need to report errors - instead of transcribing the error or trying to remember it they can just copy/paste it. For this reason the text at the top of the OIB should be selectable, as should the text in HTTPAuth dialog (not sure why the text there is divided into two separate fields, but that is for another bug).

Deleted: Screen Shot 2016-06-05 at 8.03.41 PM.png 94.8 KB

	Screen Shot 2016-06-05 at 8.03.41 PM.png 94.8 KB View Download

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I looked into this a bunch. The basic problem here is that views::Label does not support text selection at all; there's no way to enable it, so we'll have to implement it. I filed  https://crbug.com/630365  for that.

Some parts of views UI just use read only textfields with the same background as the dialog to emulated selectable Labels. See the Cookie info in the Collected Cookies dialog, in particular the value for fields like Name, Content etc. Code-https://cs.chromium.org/chromium/src/chrome/browser/ui/views/cookie_info_view.h?cl=GROK&gsn=SetEnabled&q=CookieInfoVie&sq=package:chromium&l=30. 

Though seems it has its own drawbacks. Placing the cursor within the textfield causes the cursor to blink. Maybe just subclassing Textfield can help with these though.

Read-only textfields also lack multi-line support.
Ellyjones, are you still trying to make labels selectable?

Here's where this bug was:

views::Label does not support text selection at all. views::Textfield does, and all the logic for selecting text with the mouse and so on is actually inside views::Textfield. However, you can't necessarily use views::Textfield as a drop-in replacement for views::Label, since views::Label supports multi-line text with wrapping and views::Textfield does not support multi-line text.

For this particular use, we might be able to get away with a views::Textfield, as long as we can guarantee the text is one line. If it could be multiple lines, we need to either:

1) Implement selection support in views::Label, by extracting the code from views::Textfield and making it reusable.
2) Implement multi-line text support with wrapping in views::Textfield

And then we need to implement multi-line text support in RenderTextMac either way.

karandeepb@, want to take a look? :)

So I read a bit about the state of the different RenderText implementations,
Currently RenderTextMac (which we use for Labels) does not support text selection. So for MacViews, we would also need to implement selection for RenderTextMac. But I think the plan is to move to RenderTextHarfbuzz completely. So don't think we should be spending time working on RenderTextMac. 

We could change Labels to use RenderTextHarfbuzz, but I found a comment by tapted@ that there are the following blockers for it-
"-We pop-up NSMenus on top of views::Labels in Comboboxes -- we need the layout to match, and NSMenu will never use Harfbuzz
-I need to ensure the performance is comparable"

A question for tapted@ once he returns: given that NSMenu text layout can't/won't ever match up with Harfbuzz, does this effectively mean we will never switch to Harfbuzz?

(Standardizing terminology.)

Merging this into  issue 437993 .