Open Bug 1394703 Opened 8 years ago Updated 3 years ago

Copy from elements with user-select: none

Categories

(Core :: DOM: Serializers, defect, P3)

54 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: tkbremnes, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: 1) Create an element,`<textarea>` or `<input>`. 2) Add a value to this element. 3) Make the element non-selectable by setting (vendor prefixed) `user-select: none`. Notice that the element is non-selectable. 4) Programmatically select the element (I use `$0.select()` in the devtools, with a slight `setTimeout` delay to make sure that the document is in focus). Note that the text now is selected. 5) Copy the text, either programmatically (using `execCommand`) or using `Cmd+C` Actual results: Input box text selected. No text was copied. Expected results: One of the two: 1) The text should not have been selected 2) The text should have been copied Note that the behavior in Chrome is (2).
Component: Untriaged → Editor
Product: Firefox → Core
(2) seems reasonable to me. Does Chrome also have that behavior for non-editable elements, say <span> and <div>?
Component: Editor → Serializers
Flags: needinfo?(tkbremnes)
Non-editable content doesn't have the `select()` function, not even with the `contentediable` set, so not though that way. So to test the noneditable elements, I had to play a little with `document.createRange()`. Here I found that Chrome doesn't allow you to select non-editable text at all (and doesn't copy anything). Firefox on the other hand do let you select text, _and_ it lets you copy it (unlike what happens when you select editable fields using `element.select()`). I created a jsbin for you to observe the different behaviors: http://jsbin.com/moxaxihada/1/edit?css,js,output
Flags: needinfo?(tkbremnes)
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.