fwiw: much of the old chrome://settings was not selectable either

we should probably just be more consistent with ourselves

also, we should probably stop trying to be like native UI (though I believe much of the time we added -webkit-user-select: none; to support clicking or double-clicking in <label>s actually toggling the associated checkbox rather than just making a text selection)

Good question -- we want to let people get useful info from the page, but we don't want to optimize it for filing bugs :-) Let's have Alan weigh in once he's back.

For what it's worth, I agree that a nice benefit of web pages is being able to copy text and regardless of our general decision some parts of Settings should still be selectable (eg. version info)

 Issue 623845  has been merged into this issue.

 Issue 627446  has been merged into this issue.

 Issue 644749  has been merged into this issue.

 Issue 639991  has been merged into this issue.

A lot of the platform properties on the About page are now selectable. We should do a scan of the page to make sure anything else that should be selectable is.

Anecdotally, I come to any website with the expectation that text is selectable. I also understand the rationale for turning it off to support clicking and double clicking. 

Option 1: 
In the name of consistency, I'd rather enable text selection for all webUI because it doesn't break clicking and double-clicking a label or row to complete an action.

Understandably, the setting will be toggled when trying to highlight but that use case will be pretty rare outside of bug filing. 

With that said, chrome://history seems to accomplish text selection without checking the box so maybe that's already been figured out? 

Option 2: 
Go the About://chrome route, where the non-actionable text is selectable, and actionable text is not. That would still be consistent with extensions and history. 

OK, so proposal is that any text that doesn't do something when clicked should be selectable.

Given that, maybe we could start by only preventing selection on content where we also show the pointer cursor? @dbeam what do you think?

it's not clear whether webui is Chrome UI or a webpage, so either expectation (unselectable, selectable) are equally likely, IMO

I don't think this is a beta blocker.

I'm no longer working on Chrome, and unlikely to fix any bug I'm currently assigned.

So this bug doesn't languish, I'm unassigning myself.