Closed Bug 253870 Opened 21 years ago Closed 6 years ago

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

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla76
Tracking Flags:
Tracking Status
firefox76 --- fixed

People

(Reporter: mozilla, Assigned: emilio, Mentored, NeedInfo)

References

(
URL
)

Details

Attachments

(1 file, 2 obsolete files)

Bug 253870 - Make disabled form controls selectable. r=masayuki
47 bytes, text/x-phabricator-request
Details | Review
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
Closed: 21 years ago
OS: Windows 98 → All
Resolution: --- → INVALID
Ooh, 'readonly' eh? Didn't know about that one. Thanks!
Status: RESOLVED → VERIFIED
*** Bug 317266 has been marked as a duplicate of this bug. ***
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.
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.
This appears to be a duplicate of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=195361
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.
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.
+1 for this. Make this fixed! 10 years of comments... nice. Readonly should not use as a workaround.
(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: useragent
Status: VERIFIED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
+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!
I started using IE again because of this bug.
+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
+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.
+1 to fix this.
+1 to fix this
+1 to fix this. Come on. Every other browser is doing it right.
+1 to fix this.
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/
+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.
+1 fix this please.
+1 fix this please.
+1 fix please
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.
URL: http://digitalroutes.co.uk/disabledfo... → https://jsfiddle.net/d_toybox/9pykn7x...
Flags: needinfo?(masayuki)
See Also: → 1511798

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.

(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

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

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.

Assignee: nobody → emilio

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.

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

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

Attachment #9132666 - Attachment description: Bug 253870 - Clear focused selection on focus change. r=masayuki → Bug 253870 - Hide focused selection on focus change. r=masayuki
Attachment #9132725 - Attachment is obsolete: true
Attachment #9132666 - Attachment is obsolete: true
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9eeee9ec66d9 Make disabled form controls selectable. r=masayuki,MarcoZ
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3d8f1d454ced Make disabled form controls selectable. r=masayuki,MarcoZ
Flags: needinfo?(emilio)

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

Status: REOPENED → RESOLVED
Closed: 21 years ago → 6 years ago
status-firefox76: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Blocks: 1623837

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 :)

Regressions: 1676785

I'm still facing this on Firefox 84

(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?

Flags: needinfo?(mateush.honorato)
See Also: → 1779269
Regressions: 1832275
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: