New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 881308 link

Starred by 8 users

Issue metadata

Status: WontFix
Owner:
Closed: Sep 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Input[readonly] not working user-select:none css

Reported by muammer.yilmaz@nuweb.com, Sep 6

Issue description

UserAgent: 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:
 
Labels: Needs-Triage-M68 Needs-Bisect
Components: -Blink>Input Blink>Forms>Text
Cc: viswa.karala@chromium.org
Labels: Triaged-ET Needs-Feedback
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!
https://jsfiddle.net/mylmz10/6L32cfbk/2/

See the fiddle. 

-Div can't selectable. But you can select input value although it can selectable.
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 10

Labels: -Needs-Feedback
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
Components: Blink>Editing>Selection
Status: Available (was: Unconfirmed)
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.

Cc: vamshi.kommuri@chromium.org
Labels: -Needs-Bisect
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!
Labels: -Needs-Triage-M68 Needs-Bisect
We still want to bisect.

Labels: -Pri-2 -Needs-Bisect RegressedIn-62 Target-70 Target-71 M-71 Needs-Triage-M68 FoundIn-71 FoundIn-70 FoundIn-69 Target-69 hasbisect OS-Linux OS-Mac Pri-1
Owner: tkent@chromium.org
Status: Assigned (was: Available)
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!
Cc: yoichio@chromium.org yosin@chromium.org
> Suspecting: https://chromium.googlesource.com/chromium/src/+/b01af0b296ecb855aac95c4ed335d188e6eac2de

Oh, is this behavior intentional? yosin@ or yoichio@?

Status: WontFix (was: Assigned)
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.
Cc: srsridhar@chromium.org r...@opera.com
 Issue 340671  has been merged into this issue.

Sign in to add a comment