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
Ooh, 'readonly' eh? Didn't know about that one. Thanks!
*** 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.
+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/