+cc because you were discussing clicks (and other mouse events) on disabled form controls ("Intent to Ship: Send Mouse Events to Disabled Form Controls").

Chrome does not send 'click' events to disabled text fields. This is according to spec. To me it feels wrong/unexpected that selections can be made where clicks cannot.

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

commit ba7c210328c00a6693ddc5da6504f8520bb3bdc2
Author: Hugo Holgersson <hugoh@opera.com>
Date: Fri Sep 22 17:59:09 2017

Ignore <input> and <textarea>'s user-select styling

Background:
The CSS spec says that user-select does "selective inheritance",
see https://drafts.csswg.org/css-ui-4/#propdef-user-select.

<input> and <textarea> are two elements that are affected
by this. These elements should not inherit user-select from
parent elements.

Fixed problem:
<input|textarea readonly|disabled> could inherit
"user-select: none".

This regressed because
https://chromium-review.googlesource.com/570246
removed input|textarea's default user-select styling.

Solution:
Make all text controls always selectable. This is done in
LayoutTextControl::AdjustInnerEditorStyle.

Interoperability note:
<input readonly style="user-select: none"
value="Chrome 61 cannot select this.">. This CL fixes
this by ensuring that all text fields (i.e also readonly fields)
are always selectable (no matter user-select styling).

In other words, <input> and <input readonly> now behave in
the same way (both always allow selections) which aligns
us with Firefox and Edge.

BUG= 761433 , 764316

Change-Id: I89fc94a2a04caf3a87b12a9071081dafd48a8727
Reviewed-on: https://chromium-review.googlesource.com/663217
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Hugo Holgersson <hugoh@opera.com>
Cr-Commit-Position: refs/heads/master@{#503793}
[modify] https://crrev.com/ba7c210328c00a6693ddc5da6504f8520bb3bdc2/third_party/WebKit/Source/core/input/EventHandlerTest.cpp
[modify] https://crrev.com/ba7c210328c00a6693ddc5da6504f8520bb3bdc2/third_party/WebKit/Source/core/layout/LayoutTextControl.cpp

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

commit b01af0b296ecb855aac95c4ed335d188e6eac2de
Author: Hugo Holgersson <hugoh@opera.com>
Date: Tue Sep 26 19:17:54 2017

Ignore <input> and <textarea>'s user-select styling

Background:
The CSS spec says that user-select does "selective inheritance",
see https://drafts.csswg.org/css-ui-4/#propdef-user-select.

<input> and <textarea> are two elements that are affected
by this. These elements should not inherit user-select from
parent elements.

Fixed problem:
<input|textarea readonly|disabled> could inherit
"user-select: none".

This regressed because
https://chromium-review.googlesource.com/570246
removed input|textarea's default user-select styling.

Solution:
Make all text controls always selectable. This is done in
LayoutTextControl::AdjustInnerEditorStyle.

Interoperability note:
<input readonly style="user-select: none"
value="Chrome 61 cannot select this.">. This CL fixes
this by ensuring that all text fields (i.e also readonly fields)
are always selectable (no matter user-select styling).

In other words, <input> and <input readonly> now behave in
the same way (both always allow selections) which aligns
us with Firefox and Edge.

BUG= 761433 , 764316
TBR=hugoh@opera.com

(cherry picked from commit ba7c210328c00a6693ddc5da6504f8520bb3bdc2)

Change-Id: I89fc94a2a04caf3a87b12a9071081dafd48a8727
Reviewed-on: https://chromium-review.googlesource.com/663217
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Hugo Holgersson <hugoh@opera.com>
Cr-Original-Commit-Position: refs/heads/master@{#503793}
Reviewed-on: https://chromium-review.googlesource.com/685655
Reviewed-by: Hugo Holgersson <hugoh@opera.com>
Cr-Commit-Position: refs/branch-heads/3202@{#453}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/b01af0b296ecb855aac95c4ed335d188e6eac2de/third_party/WebKit/Source/core/input/EventHandlerTest.cpp
[modify] https://crrev.com/b01af0b296ecb855aac95c4ed335d188e6eac2de/third_party/WebKit/Source/core/layout/LayoutTextControl.cpp

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

hugoh@, do you know if the underlying interop issue is still there? Are the tests in web-platform-tests that Chrome is failing?