46

I have a input text box disabled:

   <input type="text" name="name" disabled="disabled" />

In IE and in Chrome you can copy and paste the value populated in that input field but in Firefox you cannot.

Firefox does not allow clipboard manipulation through JavaScript for valid security concerns.

Any suggestion? Is there a work around this?

SergioKastro
  • 875
  • 4
  • 15
  • 22
  • 3
    As an update: [Chrome is now switching](https://bugs.chromium.org/p/chromium/issues/detail?id=626581) to doing things the same way as Firefox. I'm sure IE, er, I mean Edge will follow suit in a few years when they get around to it :) – Trevor Jul 15 '16 at 17:22
  • @Trevor. Yes, now it is not copyable in chrome. I think this change is from 54 version – Raviteja Avvari Nov 02 '16 at 11:05
  • Looks like the spec is evolving: https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute – Trevor Nov 02 '16 at 16:58
  • Found an answer here: https://superuser.com/questions/919625/how-to-paste-text-into-input-fields-that-block-it/1341611#1341611 – JinSnow Jul 19 '18 at 16:52

6 Answers6

48

readonly="readonly" will do the job

it should be supported by the major browsers

Teneff
  • 30,564
  • 13
  • 72
  • 103
  • 4
    Never, never, NEVER use readonly="readonly". See my solution for why. – Derek Mar 16 '14 at 15:03
  • 12
    I can appreciate why you might choose not to use `readonly`, but I don't think it's the type of thing that someone should never do. It's certainly not an anti-pattern. – Trevor Jan 11 '16 at 16:40
  • 1
    I would argue that it IS an anti-pattern. Put two fields on a form with some default data in each and make the second read-only. Edit the first and hit tab. The default styling of the second field is almost identical to the editable field's with almost no cues that the now selected text is read-only. It is very tempting to hit the back-space key to delete it before replacing it. This has bitten me in any number of web applications over the years, my own and other people's, and caused me to lose entire forms worth of input which I had to retype. – Derek Jun 10 '16 at 16:59
  • 3
    Well, Chrome has now disabled the backspace button to navigate back so at least that old problem goes away. As far as read-only goes,what is missing is the browser giving some visual indicator that the field cannot be edited. I know, I can easily style, but the default style should be giving me something – peater Nov 08 '16 at 14:51
  • 1
    @Derek could you not style the readonly field to look disabled so that the user doesn't think it's editable? I know it's not technically in scope but it would solve readability issues. – Jacob Morrison Mar 23 '17 at 17:55
  • @JakeMorrison, it would still receive focus via tab. – Derek Mar 24 '17 at 20:42
  • @JakeMorrison if you are not going to submit the data you can even use div and style it like the input – Teneff Mar 25 '17 at 07:44
  • @Derek if its readOnly, you WANT the field to have a tab-index. How else are screen readers going to get to the field and read the information to the user? – QT Ray Aug 26 '19 at 16:23
26

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 read-only 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. Also very, very bad when using some single-page web application, where 'back' takes you to a whole other world, and 'next' doesn't even restore your form, much less its data.

I've worked around this by rendering DIVs instead of input fields when I need the field disabled (or PRE instead of a textarea). Not always easy to do dynamically but I've managed to make fairly short work of it with AngularJS templates.

If you have time, head over to the Mozilla Bugzilla and ask them to fix it.

Derek
  • 1,466
  • 15
  • 24
  • 7
    The behavior you describe is exactly what I would expect of a readonly control. I would want it to be focusable and reachable via tab. If this isn't the desired behavior, then it would probably be better to use the 'disabled' attribute. As for the backspace issue, if it's necessary, you can prevent the default behavior in the `keydown` event. – Trevor Jan 11 '16 at 16:48
  • 1
    Actually, you are right, "readonly" controls behave exactly as I would expect them to, the behavior is consistent across browsers, and I have never liked the implications for any application I have ever worked on, so I never use them. The "bug" I am requesting be fixed is the FF one that prevents copy/paste in disabled controls. If that were fixed, then I could use "disabled" and get the behavior I am looking for. – Derek Jan 19 '16 at 18:30
  • 2
    I'm on a Mac, and Firefox 47 doesn't interpret a backspace in a readonly input as "navigate back". Also, the cursor doesn't blink like it does for editable inputs, so that's another indicator. I do agree that "disabled" should allow copying of text, though. (Also, disabled inputs don't match when finding text on the page, which is also annoying.) – Kelvin Jun 14 '16 at 19:57
  • Totally agreed @Derek. This comment is to inform you that Chrome Canary (the beta chrome) is starting to forbid the user selection on disabled inputs... This is going to give me headaches and force me to write some `
    ` or `
    ` as you suggest, instead of saying "Go to chome"
    – Nicolas Thery Sep 13 '16 at 14:11
  • 3
    Modern browsers no longer have backspace navigate back (e.g. current Chrome and Firefox). Use readonly and ignore this 3 year old FUD. – JDiMatteo Nov 11 '17 at 02:03
  • As of Jan 2020 (Firefox 71) still **does** navigate back upon backspace keypress. – xryl669 Jan 02 '20 at 18:19
6

tl;dr: Support for selecting and copying text in a disabled field is unreliable; use the readonly attribute or a non-input element, such as a <span> instead, if this functionality is necessary. Use JavaScript to modify the behavior of the readonly input to prevent unwanted behavior such as going back a page when someone hits the backspace key while the readonly input has focus.

*UPDATE: 2018.12.24

The spec has changed since this answer was originally posted (thanks to Wrightboy for pointing this out); it now includes the following caveat with regards to disabled fields:

Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this standard.

https://html.spec.whatwg.org/multipage/input.html#the-readonly-attribute

Disabled fields still cannot receive focus nor click events.

Because the standard does not define whether or not text within disabled controls can be selected or copied and because at least one major browser doesn't support that functionality, it's probably best to avoid relying on that behavior.

Original Answer

This is the expected behavior for a disabled field (as of the original date of this answer). IE and Chrome are being generous, but Firefox is behaving appropriately.

If you want to prevent the user from changing the value of the field, but you still want them to be able to read it, and/or copy it's value, then you should use the readonly attribute. This will allow them to set focus to the element (necessary for copying), and also access the field via the tab button.

If you are concerned about a user accidentally hitting the backspace button inside the readonly field and causing the browser to navigate back a page, you can use the following code to prevent that behavior:

document.addEventListener("DOMContentLoaded", function() {
  var inputs = document.querySelectorAll('[readonly]');
  for(var i=0; i < inputs.length; i++){
    inputs[i].addEventListener('keydown', function(e){
      var key = e.which || e.keyCode || 0;
      if(key === 8){
        e.preventDefault();
      }
    })
  }
});
<input value="Hello World" readonly=readonly />
Trevor
  • 13,085
  • 13
  • 76
  • 99
  • 1
    Your code doesn't work for fields added to the form dynamically, or with their style altered dynamically. Also, how is it NOT a bug that I can't select the text with my mouse and hit Ctrl-C to copy it??? I can select text anywhere else on the page and copy it, even when it is not in an input field at all. Are you saying that preventing the copying of text from a disabled field is a FEATURE? Sorry for the CAPS, but I'm shocked. – Derek Jun 10 '16 at 17:09
  • Actually, the code will work for fields that are dynamically altered; you just have to adapt it to the needs of your application. For example, you could trigger the code after the dynamic DOM changes instead of on `DOMContentLoaded`. The reason I don't consider this behavior a bug is because it adheres to the [spec](https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#the-readonly-attribute), which is by definition correct behavior. The spec prohibits focus on `disabled` fields, and focus is a perquisite to keyboard or mouse input, such as copy & paste. – Trevor Jun 10 '16 at 18:56
  • `This is the expected behavior for a disabled field` This is entirely incorrect and Firefox is currently the outlier in this situation. Please see [spec for readonly](https://html.spec.whatwg.org/multipage/input.html#the-readonly-attribute) here which references disabled controls - `Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this standard.` – JWrightII Dec 17 '18 at 18:05
3

As quick answer, one can have another not disabled element to enable + copy/paste + redisable your input text, like this:

$('#btnCopy').click(function(){
   $('#txtInputDisabled').removeAttr('disabled');  
   $('#txtInputDisabled').select();
   document.execCommand("copy");
   $('#txtInputDisabled').attr('disabled','disabled');  
});

You can se my complete response to this post

dchang
  • 1,101
  • 10
  • 13
1

Refer to my post to the same question. It does the following:

  1. Makes the textbox just like readonly without using the readonly attribute on the input tag, but will honor tab index and set focus
  2. Supports all clipboard functions win and mac with mouse or keyboard
  3. Allows undo, redo and select all

Restrict HTML input to only allow paste

Community
  • 1
  • 1
Jim Dandy BOA
  • 533
  • 7
  • 13
0

You can accomplish this in share point by utilizing the contenteditable attribute as follows with jquery.

$("#fieldID").attr("contenteditable", "false");

This will allow the user to highlight the text and copy it but will not allow them to enter anything in the field.

Ron Miller
  • 23
  • 4