This feature used to work in M53

yoichio@,
We can't select contents in disabled TEXTAREA.
Could you take look?

Firefox also does same.
Authors should use the readonly property to let user select uneditable text.
At least Blink implements input element as so:
https://bugs.chromium.org/p/chromium/issues/detail?id=626581#c9

It seems that there is no spec between readonly and disabled properties in textarea,
https://html.spec.whatwg.org/multipage/forms.html#attr-textarea-readonly
but those on input element is well specified.
https://html.spec.whatwg.org/multipage/forms.html#attr-input-readonly

Reoopening. We may need to reconsider the behavior change. See  Issue 626581 .

ConOps, did we receive a significant number of feedbacks about this?

3 - 4 reports of user feedback and one report in forum. 
This is really low feedback but that could because M54 is still in pre-stable.

As of today, I can no longer copy text from disabled text box - it's very frustrating and ruins many users' workflow.

Could you use the readonly property instead of disabled ?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea

Same here had to roll back - affecting all users who have been auto updated. introduce a rollback feature into chrome to avoid these issues.

OK I understand now. This is a fixed issue as per WHATWG
https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute:attr-input-readonly

So if you want it to be copyable then make the text box readonly rather than disabled. 

We had to roll back 200 users due to this. 

I think you still should be able to copy highlight and copy the contents of a disabled text control. The biggest difference between a readonly and a disabled control is the ability to focus (tab) into it. There are many cases where you wouldn't want a user to be able to tab into a textbox BUT still be able to use the mouse and highlight it to copy it's contents. 

The previous behavior of being able to select and copy text from disabled control does not go against the spec either..

As per the spec:
 "Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this specification."

https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute:attr-input-readonly

>As per the spec:
>  "Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this specification."
Oh, I missed.
O.K. This is a regression to be fixed.

 Issue 659696  has been merged into this issue.

Let's revert 405717.

I voted for enable copy text from disabled input fields too.

The user may not be allowed to change the date but he may use the value as copy for paste in other documents. 

There are probably many systems that use disabled="disabled" in a thousands of their parts, versions and instances like Magento e-commerce.
We cannot modify all parts of these systems just with new version of Chrome. Please revert last change, employees can not copy text now from disabled fields. Thanks.

I agree this change should be reverted ASAP - it has web compat implications and so any change in behavior should be discussed as an intent with compat data etc.  

Internet Explorer 11 (no Edge here, sorry) has some weird behavior in this regard - disabled controls are not selectable at first. However, if you select from outside of the control, or press Control + A - the controls suddenly become selectable.

We use this copy/paste function for copying read only data from a vendor website in order to continue our business workflow.  While we could key the data in, it disrupts our flow and impacts our efficiency.

In looking through the HTML spec, I cannot find a distinction between a read only and disabled TEXTAREA.  

Please reinstate its previous copy/paste functionality.  The version I am using is 54.0.2840.71  m.  

I agree please revert this change. 

We reverted r405717 21d670d3e740b26dcdf63631d163c45a57d9531c as r428261 e16d4aaa97a134e73510e2bce2f99359396f690f .

Hello Team

Is there a timeline when a update will be rolled out for the user so that they can upgrade themselves to latest version to see if the issue is fixed?

Thanks

please roll this back.  very disruptive to many of our business processes.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

It has been merged into M55:
https://chromium.googlesource.com/chromium/src.git/+/4483c37f9c09cb3fc67de11a9833881918980dc8

It would be released on Dec 6th:
https://www.chromium.org/developers/calendar

 Issue 660796  has been merged into this issue.

OS=Android
This issue is verified on latest M55 beta build

Will it be possible for this to pulled into M54?

We decided not to push it into M54 because this issue is neither so much disruptive nor  must be fixed ASAP.

It is disruptive if you use Chrome for Work and have to copy/paste these 12-digit customer numbers from screens you are not allowed to edit into some other system.

Is it looking like this will be fixed on Dec 6th?  

If so this will save me from rewriting / testing a ton of code.

Yep, the code has already landed and was already merged to the upcoming Chrome 55. Keep in mind that the date is approximate, but whenever Chrome 55 is released, it will have the fix.

Verified on ChromeOS 8872.70.0, 55.0.2883.87.  Able to copy text from the disabled text box and paste.

Yup, it's working again.  Thanks for fixing this.  Drove my users crazy for a bit and lighted up the support desk.  

I can not select text on any page in aliexpress. Has problem came up again?

#38, please file new bug.