253870 - Can't copy text from disabled textarea or text input.

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Neil Fraser]

User-Agent:       Mozilla/5.0 (Linux i686; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla 1.7

This page has two form elements which are disabled, a text area and a text
input.  There appears to be no way to select the text in these disabled fields
and copy it to the clipboard.

Reproducible: Always
Steps to Reproduce:
1. Load page.
2. In one of the disabled fields: Select some text and right-click.
Actual Results:  
No text is selected, no context menu appears.  It's as though it were an image.

Expected Results:  
A context menu should appear with 'Select All' being the only available option
(unless text had been selected, in which case 'Copy' would also be available).

Opera is exactly the same, no selection or copying available.  IE 5 allows
selection (although it is broken) and copying.

Comment 1

[Mats Palmgren (inactive)]

Looking at the source code it looks like this is intentional. See:
http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsTextControlFrame.cpp#1848

Use the 'readonly' attribute instead, then selection will work.

->INVALID

Comment 2

[Neil Fraser]

Ooh, 'readonly' eh?  Didn't know about that one.  Thanks!

Comment 3

[Elmar Ludwig]

*** Bug 317266 has been marked as a duplicate of this bug. ***

Comment 5

[Norbert]

I don't believe that this is really intentional:

This seems to be a general gecko problem, since diabled edit fields cannot be
selected in Nvu/KomopoZer and with Firefox' DOM-Insopector. The latter is Bug
257623.

Comment 6

[Norbert]

I see, select and copy (and context menu) work if I use "readonly" instead of "disabled", although I don't understand what the sense of "disabled".

But I think this does not justify bug 257623 (DOM inspector) and the problem of Nvu/KomopoZer.

Comment 8

[Adam]

This appears to be a duplicate of this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=195361

Comment 10

[Derek Price]

This bug really shouldn't be marked INVALID.  I do not believe it is intentional either.  It differs from the behavior of every other browser and why in the world would you EVER render text yet disable copy & paste?!?!?!

As far as using readonly="readonly" as a workaround, I HATE that option.  I don't like using readonly="readonly", EVER.  It leaves the field focusable and reachable via tab keypress and, if, god forbid, the user hits the backspace key while the field is focused, then most browsers treat it like the user hit the 'back' button and bring up the previously viewed page.  ***Not*** what you want to see happen when you're filling out a large form, especially if you are using some archaic browser that doesn't preserve the form data when you hit the 'next' button to return to it.

Please, please, Please, PLEASE, reopen this BUG and just FIX it.  This almost has to be something that one of the UI devs should be able to make quick work of.

Comment 11

[Duncan MacRae]

This is such a huge pain to work around. Huge! I can't believe this is still an issue. We are telling our users to use chrome if they want to select text.

Comment 12

[Károly Marton]

+1 for this. Make this fixed!
10 years of comments... nice. Readonly should not use as a workaround.

Comment 13

[Stewart Gordon]

(In reply to Károly Marton from comment #12)
> +1 for this. Make this fixed!
> 10 years of comments... nice. Readonly should not use as a workaround.

It isn't a workaround - it's the correct attribute to use when the user should still be able to focus the control / copy text from it.

But there are some websites that use disabled where they should be using readonly.  Moreover, even if disabled is the correct attribute to use, it's a principle of the web that you can't force anything, and as such users should still be *able* to copy text from a disabled control if they want to.  The browser is the user's tool, not the developer's.  As such, I'm reopening this.

Comment 14

[marc]

+1 for having it reopened again.

To copy text I go into the inspector (F12), edit the HTML and then I can copy the field's contents.

I like Firefox very much and use it 24/7, so I suggest that this trouble can be fixed in version 39.1

Thanks!

Comment 15

[fish4FF]

I started using IE again because of this bug.

Comment 16

[zeppelin]

+1(In reply to marc from comment #14)
> +1 for having it reopened again.
> 
> To copy text I go into the inspector (F12), edit the HTML and then I can
> copy the field's contents.
> 
> I like Firefox very much and use it 24/7, so I suggest that this trouble can
> be fixed in version 39.1
> 
> Thanks!

+1

Comment 17

[schragmanuel]

+1 to fix this

In Chrome (V 54.0.2840.99), I can work around the problem by setting the field readonly and tabindex="-1". When I click in this field, the text is selected and I can copy it. Doing the same in Firefox (V 50) I can click in the field, but text is not selected and thus can not be copied.

Comment 18

[Giannis Koutsaftakis]

+1 We are telling our users to switch to Chrome or IE for this.

Comment 19

[Tolis]

+1 to fix this.

Comment 20

[chance_comer]

+1 to fix this

Comment 21

[Muris]

+1 to fix this. Come on. Every other browser is doing it right.

Comment 22

[vignesh.professional]

+1 to fix this.

Comment 23

[Lorenzo]

I think this is very unintuitive to have a behavior like this since the spec does not prohibit (it's unspecified) the marking and copying of the text in a disabled input or textarea. In ither browsers, tested on Chrome 58 and Safari 11, I'm able to mark and copy the text.

What I would expect:
* Mark the text with double click
* Be able to copy the marked text with shortcut or context menu
 
specification: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#enabling-and-disabling-form-controls:-the-disabled-attribute
example: https://jsfiddle.net/b05c7kcz/

Comment 24

[mark.maddox]

+1 to fix this.  This is a stupid problem.  Fix it already!!!
At least provide an option in settings to turn the blocking of text-copy off for read-only fields.

Comment 25

[Andreas]

+1 fix this please.

Comment 26

[Evantchapman]

+1 fix this please.

Comment 27

[martijn.halekor]

+1 fix please

Comment 28

[tk]

I created a bugzilla account just to +1 this. This is very annoying, and there is no excuse for a bad ux. Browser that doesn't let the user do what she wants (eg. copy a text that is on the screen) is a bad browser.

Comment 29

[Emilio Cobos Álvarez (:emilio)]

I'm pretty sure the line responsible for this is:

  https://searchfox.org/mozilla-central/rev/ecf61f8f3904549f5d65a8a511dbd7ea4fd1a51d/editor/libeditor/EditorEventListener.cpp#973

If someone wants to write a patch I'm happy to mentor, or I can try to write it myself when I get some free time.

Comment 30

[Emilio Cobos Álvarez (:emilio)]

I took a quick look, it's not as easy, since disabled inputs / textarea elements are not focusable. I got it to work but not paint the selection...

Comment 31

[Emilio Cobos Álvarez (:emilio)]

So to elaborate on the above...

The way this works, if I'm not wrong (not the most familiar with editor), is that each <input> / <textarea> element has an editor instance associated, and its own independent selection. This includes disabled form controls.

You _can_ select text on them (not copy though), we just hide the selection.

The way the selection works for other controls is that we hide it when blurred, and show it when focused. This is problematic for disabled elements because they don't get focused (other browsers don't focus them either). For example:

<style>
textarea { color: red }
textarea:disabled { color: green }
textarea:focus { color: orange }
</style>
<textarea disabled>Foo bar baz</textarea>

Will never show orange text anywhere.

Blink and Webkit seem to preserve the selection on blur, so they hide it via another mechanism. At least, if you have a document like: <textarea>Foo bar baz</textarea>, select something in the text area, then Shift+Tab they'll keep showing the selection. Not sure yet what they do in that regard, but switching to such a model where focusing on another element hides the selection could be a solution.

WebKit and Blink do not seem to preserve the selections across textareas. For example, if I do:

  <textarea>Foo bar baz</textarea> <textarea>Foo bar baz</textarea>

Then select something in the first textarea, pres tab, then shift+tab, my selection is not preserved.

So we either change the "hide selection on blur" mechanism to do it at some other point (when?), or I don't have a good idea of how to fix it.

An alternative is to not give disabled inputs their own independent selection. That sounds a bit like a can of worms, but maybe it's easier? I don't know.

Maybe Masayuki has thoughts?

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)
> So to elaborate on the above...
> 
> The way this works, if I'm not wrong (not the most familiar with editor), is
> that each <input> / <textarea> element has an editor instance associated,

Right.

> and its own independent selection.

Right. SelectionController is nsTextInputSelectionImpl, it's created with independent nsFrameSelection instance so that all Selection instances are created per TextEditor instance.


> This includes disabled form controls.

Yeah, I just read the code briefly, but looks like that those instances are created when anonymous nodes are created by frame constructor without any disabled state check.  This is redundant if we'd keep disabling any interaction.

> You _can_ select text on them (not copy though), we just hide the selection.
> 
> The way the selection works for other controls is that we hide it when
> blurred, and show it when focused. This is problematic for disabled elements
> because they don't get focused (other browsers don't focus them either).

Well, EditorBase::InitializeSelection() and EditorBase::FinalizeSelection() do that when they are called by focus/blur event listeners.

> textarea:focus { color: orange }
> </style>
> <textarea disabled>Foo bar baz</textarea>
> 
> Will never show orange text anywhere.

Well, even if I put tabindex, "disabled" state wins to control if focusable. I'm not sure if this is valid behavior.
https://jsfiddle.net/d_toybox/9pykn7x0/4/

> Blink and Webkit seem to preserve the selection on blur, so they hide it via
> another mechanism. At least, if you have a document like: <textarea>Foo bar
> baz</textarea>, select something in the text area, then Shift+Tab they'll
> keep showing the selection. Not sure yet what they do in that regard, but
> switching to such a model where focusing on another element hides the
> selection could be a solution.

Or, EditorBase::InitializeSelection() might work if we call it from mousedown listener if disabled.

> WebKit and Blink do not seem to preserve the selections across textareas.
> For example, if I do:
> 
>   <textarea>Foo bar baz</textarea> <textarea>Foo bar baz</textarea>
> 
> Then select something in the first textarea, pres tab, then shift+tab, my
> selection is not preserved.

Well, if we make all <input>/<textarea> in a document share selection, could be implemented simply, and we can reduce a lot of memory.

> So we either change the "hide selection on blur" mechanism to do it at some
> other point (when?), or I don't have a good idea of how to fix it.
> 
> An alternative is to not give disabled inputs their own independent
> selection. That sounds a bit like a can of worms, but maybe it's easier? I
> don't know.

Hmm, perhaps, not easy because the range is in anonymous contents but accessible from web apps via Selection API.

Comment 33

[Alexander J]

Similar issue but with another tag <script type="text/plain">: https://bugzilla.mozilla.org/show_bug.cgi?id=1535392

May it would help to resolve this long standing issue.

The only difference between bugs, is that in case of disabled text/texarea tags - firefox disallows even to select content, while with <script type="text/plain">, firefox allows to select and copy, but if one would try to paste copied content, he/she will paste nothing.

Comment 35

[gnopap]

16 Years and counting. Sorry but LOL! Seems FF is becoming the new IE with weird behaviour forcing devs to do specul workarounds.

Closing tickets and +1 as if that is somehow easier than to bloody fix that absolutely trivial issue.

Comment 36

[gnopap]

(In reply to gnopap from comment #35)

16 Years and counting. Sorry but LOL! Seems FF is becoming the new IE with weird behaviour forcing devs to do specul workarounds.

Closing tickets and +1 as if that is somehow easier than to bloody fix that absolutely trivial issue.
I'm sorry I might have been a little indignant. If I could I would delete this comment. I really do appreciate making FF possible.

<3

Comment 37

[simon.campano]

+1 for a fix, this is making our users stay on other browsers.

Comment 38

[Emilio Cobos Álvarez (:emilio)]

I gave this a shot out of curiosity.

(In reply to gnopap from comment #35)

Closing tickets and +1 as if that is somehow easier than to bloody fix that absolutely trivial issue.

This happens to be not-so-trivial, actually. <input disabled> is not allowed to take focus per spec, and our editor code mostly works when the input is focused (which is true for every other input). Anyhow I think I have a patch that may work. But let's see what others think.

Comment 39

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 253870 - Make disabled form controls selectable. r=masayuki

Tests needed, of course... This matches other browsers modulo one thing, which
is that if you have something like:

<input disabled value="abc"> def

And select abc, then def we don't hide the selection from the <input>,
because that's usually the job of the EditorEventListener's blur handler via
setting the selection to SELECTION_HIDDEN.

I have an alternative approach for that incoming, and I'd like your feedback on
that.

Comment 40

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 253870 - Hide focused selection on focus change. r=masayuki

When the selection changes, clear the old one instead of hiding it using
SELECTION_HIDDEN.

I think this is slightly better than what we were doing, and fixes the use case
of <input disabled>, wdyt?

Depends on D66464

Comment 41

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 253870 - Fix actually copying text from a disabled input. r=masayuki

I was testing above selecting text, naively thinking copying would just work...

Hopefully fixing it is trivial, and also cleans up a bunch of code.

Tests still needed, will send in a separate patch.

Depends on D66465

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9eeee9ec66d9
Make disabled form controls selectable. r=masayuki,MarcoZ

Comment 43

[Alexandru Michis [:malexandru]]

Backed out changeset 9eeee9ec66d9 for causing failures in browser_bug1261299.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/0dd184191288d3bcbababfde28af171afbab74a1

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=293382638&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&fromchange=e87acf21935d5ff91c3e9dafe554a314ad31fd2b&tochange=0dd184191288d3bcbababfde28af171afbab74a1&test_paths=browser%2Fbase%2Fcontent%2Ftest%2Fgeneral

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293382638&repo=autoland&lineNumber=1511

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3d8f1d454ced
Make disabled form controls selectable. r=masayuki,MarcoZ

Comment 45

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/3d8f1d454ced

Comment 47

[John Nguyen]

Hi,

I can still replicate the issue if the page contains another contenteditable element.
Minimal reproduction page: https://codesandbox.io/s/condescending-hermann-8zttt?file=/index.html:375-390

I filed it as a separate bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=1664114 :)

Comment 48

[mateush.honorato]

I'm still facing this on Firefox 84

Comment 49

[Emilio Cobos Álvarez (:emilio)]

(In reply to mateush.honorato from comment #48)

I'm still facing this on Firefox 84

Can you file a new bug with a test-case that reproduces it?