CTRL+A should not mark <input type="button" value="text">'s text
Reported by
hu...@opera.com,
Jul 25 2017
|
|
Issue description
This bug is not visible to end users because html.css (Blink's user agent stylesheet) hides the selection:
input[type="button" i] ... {
...
-webkit-user-select: none;
...
}
Bug: CTRL+A should not select button text.
Goal: |user-select: auto| should always do the right thing (= no changes should be needed in html.css).
Interop:
- This works in Firefox 54.0.1.
- Firefox also treats <button> in the same way: Firefox's CTRL+A selects neither <input type=button>'s nor <button>'s text.
,
Jun 18 2018
What's the motivation of this issue that |user-select: auto| should make a text inside a button unselectable w/o |user-select: none|?
,
Jun 18 2018
As a user, I expect buttons' text to not be selectable by default. I created this bug because I thought it was preferable to not add rules to html.css - but as Firefox already has this rule, I guess it makes sense for us to copy it Chrome? |
|
►
Sign in to add a comment |
|
Comment 1 by tshin...@gmail.com
, Jun 16 2018Selection of button text is also happening on double- and triple-clicks anywhere within a web page, even in the face of preventDefault() and the like. Switching from <button>hiya</button> to <input type="button" value="hiya" /> stops selection of the button text. Manually applying "user-select: none;" to surroundings of buttons also 'works'. Whereas Chrome has only a CSS guard for input[type="button" i], input[type="submit" i], input[type="reset" i] { user-select: none; } Firefox has button, input[type="color"], input[type="reset"], input[type="button"], input[type="submit"] { -moz-user-select: none; } Is this really just Chrome missing browser CSS defaults? This on Canary 69.0.3461.2