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

REOPENED
Unassigned

Status

()

REOPENED
15 years ago
13 days ago

People

(Reporter: mozilla, Unassigned, Mentored)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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.
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
OS: Windows 98 → All
Resolution: --- → INVALID
(Reporter)

Comment 2

15 years ago
Ooh, 'readonly' eh?  Didn't know about that one.  Thanks!
Status: RESOLVED → VERIFIED

Comment 3

13 years ago
*** Bug 317266 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 403081

Comment 5

11 years ago
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

11 years ago
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.
Duplicate of this bug: 527902

Comment 8

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

Comment 10

5 years ago
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

4 years ago
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

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

Comment 13

4 years ago
(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.
Blocks: 86194
Status: VERIFIED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---

Comment 14

4 years ago
+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

3 years ago
I started using IE again because of this bug.

Comment 16

3 years ago
+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

2 years ago
+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.
+1 We are telling our users to switch to Chrome or IE for this.

Comment 19

2 years ago
+1 to fix this.

Comment 20

2 years ago
+1 to fix this

Comment 21

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

Comment 23

a year ago
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

8 months ago
+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

7 months ago
+1 fix this please.

Comment 26

6 months ago
+1 fix this please.

Comment 27

2 months ago
+1 fix please

Comment 28

17 days ago
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.
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.
Mentor: emilio
Component: Layout: Form Controls → Editor
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...
Mentor: emilio → nobody
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?
Flags: needinfo?(masayuki)
(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.
You need to log in before you can comment on or make changes to this bug.