I am making an HTML textarea that accepts tab key input using JavaScript.
When I searched for a solution on the web, I found this answer, but after some fiddling, I found out that ctrl+z stops working after I hit tab key.
Doing some more experiments revealed that changing the value attribute was likely the culprit of this problem. Here is a small scale code example that you can hopefully reproduce this behavior yourself.
https://codepen.io/MartianLord/pen/gORKPGp?editors=1010
I managed to find a workaround using document.execCommand to simulate the user input, but this method is deprecated as you can see here, so I am looking for a more up to date solution.
To support ctrl+z while using tab in <textarea>, you need to implement undo, redo functions to connect with <textarea>. When the <textarea> changes, record the changes in the history, and revert when ctrl+z key input occurs.
UndoRedojs is a library for this task.
I think there will be a lot of work to be done, such as setting the selection position, in order to fully implement it. I recommend using a text editor that has already been created.
Related
I'm creating a barebones in-browser code editor with a pre marked as contenteditable. I'm listening to the input event to perform code highlighting and some other side effects.
When a user hits Shift+Enter two line breaks are inserted which confuses my program and messes up cursor positioning. Is there a way to disable this?
In my opinion one would need to be able to detect that the SHIFT and ENTER keys were pressed. However, the INPUT event does not appear to contain that data. If you can use an event listener that contains data about all keys being used for a single event, then you may be able to use something like event.preventDefault() in the callback. I do not know what the context of all your code is, so I do not know if it is feasible to use other events, specifically keypress.
I also cannot reproduce the issue you are describing. You may be using a plugin that causes the double-spacing issue.
This can be seen on Knockout.js site as well.
When I open this page in IE11 or FF 38, and go to Example 2: Click-to-edit and click on the Name - Bert Bertington, the Caret (cursor) of textbox is at the start of text, while in Chrome it is at the end.
If this is a feature, could somebody suggest how to keep the caret in the end when the label changes to textbox in IE11 and FF38.
I was able to fix this in FF38 by resetting the contents of observable as below, but his does not work in IE11.
var str = self.msg();
self.msg('');
self.msg(str);
I am using knockout-3.2.0 if that matters.
UPDATE
The issue seems to be with browsers rather than Knockout (sorry for the confusion).
I tried setting focus of the text field using JQuery and javascript .focus() functions and am still getting same result on IE11 and Firefox 38.
Any help would be appreciated.
You are correct, this is an issue of how different browsers handle the focus event. A workaround would be to manually set the cursor to the end of the text within the textbox.
An example of doing this can be found here. If you want this to happen automatically using knockout, you would have to create your own custom binding based on the hasFocus binding, or modify the KnockoutJS library directly. The focus event is triggered on line 3813 of the Knockout 3.2.0 non minified JS file.
I do not know if this happens to you but when I create a form and have a bunch of textfields inside with some type of validation (let's say maxLength) then whenever I violate this and the tooltip appears, for some reason it removes the focus from the textfield. This is really annoying because since you have gone over the max length the next step is to press "backspace" in order to delete some characters but since there is no focus in the textfield backspace executes "Back" of the browser and everything is lost. I tried to search for some related configs and stuff but I haven't found anything yet and there's nothing on the internet. It looks like this:
I saw that you are using ExtJS 5.0.2.xxx, so if you don't have a problem using nightly builds, the latest ones (from Oct 14th 2014 on) fix this bug.
Here is a report of this bug being found and fixed: http://www.sencha.com/forum/showthread.php?293325
Thanks,
Are you using ExtJS 5.0.1? I think it's a bug, I've seen the same behaviour.
As a temporary solution you can add the following to your textfield to avoid the tooltip interfering with the field focus:
msgTarget:'side' // or 'under'
While this might not be preferable as to your design guide lines - it might be better than to wait for Sencha to fix it.
I have a page with an input box, and a function that processes the value of this input box and produces piece of text. I want this text to always be up to date in relation to the contents of the input box, so I've attached a couple of event handlers to it with jQuery to catch any changes:
$('#input').bind('keyup cut paste', function(){...});
This works well in most cases. Whenever the user modifies the contents using the keyboard in any way, or right-clicks to use the cut or paste functions, the text is updated immediately. However, there are two events I still haven't figured out how catch, if it's even possible to do so:
When the user selects a of text and drags it do a different position in the input box
When the user uses the Delete action in the right-click context menu
Both of these can of course be detected by binding the change event, but the problem with that approach is that it doesn't fire until the input box loses focus. The whole point of these bindings is to have the text update in real-time as the value of the input box changes, so change is no good.
English is my second language so I could simply be bad at wording my Google searches, but so far they've turned up nothing. I haven't found any solutions to this after digging through a couple of related Stack Overflow pages either, so I'm asking here. Is there an event binding for this that I don't know of? If not, is there a different approach I could take? Or is this simply not possible with plain JavaScript?
In non-IE browsers, you can handle the input event.
In IE, you can handle the propertychange event.
Demo (works in all browsers)
It's possible this SO question (and related jsfiddle) might answer your question.
(On the linked jsfiddle, put text in the top box to test)
In other words, bind to mouseup and mousedown, etc.
If you can't find a combination of events that cover all cases, you may want to use setInterval(function() {... }, period). You could play around with the period to see how well this works.
All I need is to be able to detect when text is dropped into a Textarea. I then take that text and do stuff with it and clear the textarea. There may be many of these textareas and very high UI expectations, so polling is a last resort.
For IE, "onfocus" does the trick, since this event is fired after the user drops stuff into the textarea.
For Firefox, I can't find an event that works. I've tried onmouseup and onchange.. don't know what else to try from there. I'd hate to have to poll the textarea for content. Help much appreciated. Thanks.
Edit: For clarification, "dropped" means the user selects text (usually) from the page, but it doesn't matter where, drags it, and drops it into the textarea. This is not the same as Ctrl+V, or right click pasting (which take two different methods of detection, BTW), or (obviously) typing into the textarea. Specifically, it is the "drop" aspect of drag and drop. I really don't know how else to phrase it.
I feel this question was stated rather accurately. To humor me, assume that I meant any of the other operations on a textarea that you all have chosen to share. If I meant "pasting", don't you think I would have mentioned something about pasting in the title or content of my question? Same goes for typing in a textarea. But, perhaps, you all just don't know me well enough to know that I type what I mean, rather than mistakingly typing things only somewhat related to what I mean.
For Firefox, this works for me:
window.addEventHandler("dragdrop", function(event) {alert("Drop it like it's hot!")}, true)
Does not work in Safari, however. Haven't tried IE.
Polling seems to be the only way to go.
When a Drag+Drop operation is started within the browser, it seems to cancel out everything else that's going on. You can witness this by putting "onmouseover" events on something on the page, then starting a DnD operation and dragging over it. The events will not fire.
It seems only a coincidence of how the browser internally handles "drag and drop" that it causes onfocus() to be fired for the textarea in IE and Safari. I doubt there is much defined in the W3 specification... not that it matters, W3 is crap, and besides nobody adheres to it completely.
In my question I stated the luxury of emptying out the textarea after each use, so I feel that polling for: textarea.value.length>0 is hardly any cost and shouldn't be much of a performance concern.
But, alas, it specifically has to do with dropping content into a textarea.
Down-mod away to sooth your pain.
If you want your textarea to react to text being dropped, pasted or typed, your only solution would be a button. Even a timer polling the content will not help you.
You mention that you want the user to be able to type text in the textarea. And you mention that you want to clear the text whenever the event is fired. There is no possible way for the browser to know that the user has finished typing. You must rely on a specific action.
Now for the drop or paste, you can rely on the mouseup and keyup events in order to detect that.
What do you mean by "dropped"? Are you talking about a paste (^V) operation? If so Aron's answer is indeed correct, you will get keydown/keyup (and the value will be readable in keyup).
A generic callback that will happen on any update to an input is 'onchange' - you could try that. Note that when typing, it doesn't get called until you finish and unfocus the input, so if you need instant updates on both typing and other forms of input, you still need 'onkeyup' as well.
Edit re clarification: IMO 'onchange' should be fired when a drag-and-drop causes content to be added to a text area; I consider it a browser bug that it is not (in Firefox at least). I can only concur in this case that polling is all you have left.