I have always sucked at javascript I have read multiple books and studied online but on some things I just cannot get them to work. Anyway, I use a simple javascript function that selects all of the text in a textfield when I hover it:
<input type="text" onMouseOver="this.focus();this.select()">
how do I undo that action once the cursor is no longer over that field? This is important since I bought a new BlackBerry Bold 9930 and hate the internet browsing, but with javascript I am making things easier like highlighting all text in a field by just hovering over it. So I just need the code that unselects all of the text once I move away from that field since in the Blackberry browser it wants to stay stuck in that field highlighting the text unless I click somewhere else. Thanks.
<input type="text" onMouseOver="this.focus();this.select()" onmouseout="this.selectionStart = this.value.length; this.blur();">
http://jsfiddle.net/meQek/
it's kind of an odd way but logical when you think about it. If you highlight it all on mouseenter, the selectionEnd is at the end... so just make the selectionStart at the same position on mouseleave.
EDIT:
actually... blur works just fine :P
http://jsfiddle.net/meQek/1
<input type="text" onMouseOver="this.focus();this.select()" onmouseout="this.blur();">
Try this:
<input type="text" onMouseOver="this.focus();this.select()" onmouseout="this.blur();">
Not sure how the Blackberry browser will handle it, but in most browsers it should unfocus the text field when your mouse leaves it.
Related
This one is IE specific (not anymore, apparently). We have very simple code:
<div draggable="true">
<p>Text</p>
<input type="text"/>
</div>
On Chrome it works fine, you can select all text inside <input>, eg. double-click it or click-and-drag. On IE10 you cannot do both of these actions (not sure about IE in other versions). Any ideas?
Fiddle: http://jsfiddle.net/s5g4gr8g/
This was reported as a bug a few months back and is currently being considered for a future release.
One of the hold-ups is that we are unable to determine the impact of the issue. I recall searching online and on GitHub for sites that relied on this pattern, but largely came up empty-handed. If you happen to know of any sites that use this, and are therefore broken in Internet Explorer 10 and 11, I would be happy to update the internal issue and request immediate action.
That being said, it does appear you can select text if you tab focus to the element itself, and then utilize the arrow and shift keys to perform your selection. You can also right-click the input control, which also places a cursor that you can then manipulate with your keyboard. It's not ideal, but it may suffice until we can resolve this from the browser-end.
One possible workaround to this solution is to remove the draggable attribute from the parent element in situations where you expect the text to be highlighted.
For instance in an application I'm working on, we show text in a span by default, then reveal an input when the user clicks on it to edit. At that point we remove the draggable attribute until the user is done editing, and then readd it.
That particular flow may or may not work for you, but if you can anticipate when the user might highlight, you can minimize the effect of the undesirable browser behavior. At minimum you can toggle draggable on focus and blur so that the user can highlight with the mouse if he's already editing the text.
The way Ben McCormick mentioned works good for me on the major browsers (tested with Internet Explorer 11, Firefox and Chrome).
For my solution you need to have an criteria to determine the parent with the draggable attribute (in my case I use a class name for that).
function fixSelectable(oElement, bGotFocus)
{
var oParent = oElement.parentNode;
while(oParent !== null && !/\bdraggable\b/.test(oParent.className))
oParent = oParent.parentNode;
if(oParent !== null)
oParent.draggable = !bGotFocus;
}
<div class="draggable" draggable="true">
<p>Text</p>
<input type="text" onfocus="fixSelectable(this, true)" onblur="fixSelectable(this, false)"/>
</div>
What we observed, if we blur out and focus again the issue is resolved. However moving cursor position is still not accomplished. But at least does the trick for single click.
$(document).on('mouseup', '#id input:text, textarea', function (event) {
$(this).blur();
$(this).focus();
});
I think I may already know the answer to this one but...
Is it possible to have two carets in a single textbox, or have two separate textboxes focused at the same time allowing the user to type into both symataniously?
I know you can simulate this by adding a keydown listener and making their values match, but I want the visible caret in both fields.
If not, does anyone have any ideas on how to simulate this?
Ace editor supports multiple cursors/carets like Sublime Text:
http://ajaxorg.github.io/ace/
Ctrl+Click (or Cmd(⌘)+Click on OS X) in the live demo on that page to get multiple cursors and type away!
You can also select a bunch of code and use Tab to indent a tab space, or Shift+Tab to outdent a tab space.
Check out #Sly_cardinal answer, That does everything you require, it is more off a "heavy" solution, but is certainly the only way you'll get something like this. It can be customized with a bit of work but its definitely the correct answer.
+1 #Sly_cardinal - Just what i've been looking for!
Rendering a text area is handled by the user agent (browser), we can control the style, look and feel, but unfortunately not the functionality (To be able to do multiple cursors anyway).
Bummer.. This would be amazing!
Try
<html>
<body>
<input id="edValue" type="text" onKeyPress="edValueKeyPress()" onKeyUp="edValueKeyPress()"><br>
<span id="lblValue">The text box contains: </span>
<input id="secvalue" type="text">
</body>
<script>
function edValueKeyPress()
{
var edValue = document.getElementById("edValue");
var s = edValue.value;
var lblValue = document.getElementById("secvalue");
lblValue.value = s;
}
</script>
</html>
I suppose this is your requirement
I'm trying to run a script on an input text box that populates a div. The snippet is like so:
<input type="text" id="control" value="" />
<div id="displaydiv"></div>
<script>
document.getElementById("control").onkeydown = function() {
document.getElementById("displaydiv").innerHTML = this.value;
}
</script>
The problem here is that there is a lag of one character, i.e. if I type 'a', nothing shows up. When I type 'b', the previous 'a' shows up and so on. I tried replacing the onkeydown with onkeyup, and there is still a bit of a lag. How do I get the div to match the input text box in real time, without refreshing the page and/or losing focus on the input box?
Thanks for looking.
That is because onkeydown triggers before the key has added its value to the input. Use onkeyup instead. It will work the way you are after.
Edit: Not sure if I missed the speed thing, if you edited your question, but the lag you are seeing is unavoidable. It is as close to "real-time" as you are going to get. It's really not even that bad, less than half a second when I check it in a fiddle
Edit2: Just to satisfy my curiosity, I checked the performance against KnockoutJS's databinding, with the one input updating a div text via knockout, and another div via your script. The performance is identical. I was actually a bit surprised knockout didn't introduce any noticable overhead. Here is the fiddle
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?
readonly="readonly" will do the job
it should be supported by the major browsers
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.
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 />
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
Refer to my post to the same question. It does the following:
Makes the textbox just like readonly without using the readonly attribute on the input tag, but will honor tab index and set focus
Supports all clipboard functions win and mac with mouse or keyboard
Allows undo, redo and select all
Restrict HTML input to only allow paste
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.
I am using the code below to try and get the value to show before clicking. I want the value "reply here" to show in the texarea and when someone clicks it should go away letting them type their reponse. I am using the code below but it doesn't show the value until one click in the box. How can i tweak it?
onclick="this.value='';" onfocus="this.select()"
onblur="this.value=!this.value?'Reply
here':this.value;" value="Reply here"
textarea's dont take the "value" attribute, to set a default value of a textarea use the following:
<textarea>reply here</textarea>
I'm searching for a different answer, but thought I could shine some light on what's available with HTML5. All you need to do is do the following:
<textarea placeholder="Reply here"></textarea>
However, I'm sure it doesn't work with much older browsers, but here's a link to get backward compatibility: how to use HTML5 placeholder attribute with backward-compatibility in mind?