Input[readonly] not working user-select:none css
Reported by
muammer.yilmaz@nuweb.com,
Sep 6
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Input tag with readonly attribute 2. Add user-select:none css 3. Not working user-select What is the expected behavior? What went wrong? User-select:none should be work but doesn't anyting Did this work before? Yes 60 Does this work in other browsers? N/A Chrome version: 68.0.3440.106 Channel: n/a OS Version: 10.0 Flash Version:
,
Sep 6
,
Sep 7
Thanks for filing the issue! @Reporter: Could you please provide sample Test file/URL that reproduces the issue which help in further triaging it in better way. Thanks!
,
Sep 10
https://jsfiddle.net/mylmz10/6L32cfbk/2/ See the fiddle. -Div can't selectable. But you can select input value although it can selectable.
,
Sep 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 11
According to the specification, input[readonly] is NOT mutable, and user-select:none should work so. https://drafts.csswg.org/css-ui-4/#propdef-user-select > The computed value is the specified value, except: > 1. on editable elements where the computed value is always contain > regardless of the specified value > 2. when the specified value is auto, which computes one of the other > values as defined below > For the purpose of this specification, an editable element is either an > editing host or a mutable form control with textual content, such as > textarea. https://html.spec.whatwg.org/multipage/input.html#attr-input-readonly > The readonly attribute is a boolean attribute that controls whether or > not the user can edit the form control. When specified, the element is > not mutable.
,
Sep 11
Looks like this is already being investigated and recent change seems to be specification compliant hence removing the Needs-Bisect label...however please feel free to add the label back if this still requires a bisect. Thanks!
,
Sep 11
We still want to bisect.
,
Sep 12
Able to reproduce the issue on reported chrome version 68.0.3440.106 and on the latest canary 71.0.3548.0 using Windows 10, Mac 10.13.1 and Ubuntu 14.04 Bisect Information: ------------------ Good Build: 62.0.3202.36 Bad Build: 62.0.3202.37 providing the change log from https://omahaproxy.appspot.com/ as this seems to be regressed in branched builds. https://chromium.googlesource.com/chromium/src/+log/62.0.3202.36..62.0.3202.37?pretty=fuller&n=10000 Suspecting: https://chromium.googlesource.com/chromium/src/+/b01af0b296ecb855aac95c4ed335d188e6eac2de Review URL: https://chromium-review.googlesource.com/c/chromium/src/+/685655 Assigning it to one of the reviewers, Kent Tamura as we couldn't assign it to the author Hugo Holgersson @Kent Tamura: Please help in assigning it to the right owner if this is not related to your change. Thanks!
,
Sep 13
> Suspecting: https://chromium.googlesource.com/chromium/src/+/b01af0b296ecb855aac95c4ed335d188e6eac2de Oh, is this behavior intentional? yosin@ or yoichio@?
,
Sep 18
That is intentional and following interop: > 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.
,
Sep 25
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by viswa.karala@chromium.org
, Sep 6