Develop Reference

Extjs How to stop form tooltip from removing focus from a form textfield

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.

Reconcile Firefox slash handling and key codes

I have a webpage where users should be able to type anywhere and have their input tracked. One problem is that the slash key, "/," in firefox is a shortcut for opening the search. This is undesirable for me. I have not found a way to trap the search functionality and still add the input to my tracking. I add the input to the stack on keypress.
keydown...preventDefault works best in FireFox, but the problem is that in Chrome, keypress does not fire for some reason (not sure why preventDefault would stop that, but it does). This would be okay if I could add the slash on my own to the input stack..but Firefox is already adding it because keypress is still triggered. stopPropagation does not prevent keypress from triggering in FireFox either. $(document).keypress(e) in the keydown method also does nothing.
Another issue I have is that "backspace" is supposed to remove from the stack, but I add to the stack with String.fromCharCode(e.which) and add the data to an input type="text" field that the user can see. In Chrome this works perfectly, but in FireFox, it adds a character representing the backspace and then immediately removes it, preventing another character from being removed. Having "backspace" and "f5," etc. characters in the input is also undesirable. Is there a way to tell if the fromCharCode value is valid for a text field? I think what's happening is that Chrome just does that automatically.
EDIT: This may help, but FireFox apparently triggers keypress before keydown (Chrome does the opposite) on my webpage. This is unusual.

Solved this with a bit of a kludge. I have a noslash variable that triggers capturing the slash:
else if (e.which == '191' && !noslash) {
e.preventDefault();
$typing.val($typing.val() + '/');
}
As for the second part of the question, I simply reject any character in
[^-a-z0-9`~!##$%^&*()_+=\\|/'";:,<.>?\[\]{}]

Custom autocomplete arrow control

I am trying to make custom autocomplete input (I know about jQuery UI autocomplete, but I decided to write a simple one). Everything went fine, I did all the 'general' stuff - sending data to some PHP script, receiving suggestions. Then I enabled choosing an element on a mouse click, and also did some navigation using down arrow, up arrow and enter keys. But I got stuck with an ambition to enable 'holding down\up arrow key' navigation (flicking through). A handler on my input listens for keyup event, and I perfectly understand that all I want is keypress event, because it maintains key hold. But keypress only works for printable characters which doesn't include down arrow\up arrow. So the question is: how can I make it work without keypress, or can I somehow override this event's maintained keys?
Thanks everybody, I've found the solution. Although keypress is meant to be fired only on printable characters, latest Opera and Firefox 5 do support it. But Chrome (and probably Safari, as they are quite similar) doesn't, whereas keydown gives the result I need.

If there is no way to overcome the keypress difficulty try something like this. This is pseudocode I didn't do all the keycode detection.
var keyStop
onkeydown = function(){
keyStop = setInterval(function(){scrollDown()},250);
}
onkeyup = function(){
clearInterval(keyStop);
}

If you for some reason got stuck in your development, I would recommend Better Autocomplete, which is a lightweight jQuery plugin which is easy to customize.

Scan inputs with Opera Mobile 10

We have chosen the Opera Mobile for one PDA application, everything went well until we hit a problem with regards to taking a scanned input to one of the text fields.
The general way you'd approach this problem is by setting one textBox to have focus when the scan operation is performed.
UNFORTUNATELY, intentionally or unintentionally Opera is not supporting this. The focus is no-where when you enter in to the screen and there is no way of explicitely setting it. Worst comes next, you cannot detect the key-press events too, which makes it virtually impossible to take the input event from the scan operation.
I have no clue why Opera, one of the best acclaimed mobile browsers, does not support this.
These are the places the same question is asked over and over again,
http://dev.opera.com/forums/topic/255066
http://dev.opera.com/forums/topic/650332
http://dev.opera.com/forums/topic/384311
We have posted in the Opera Dev forum as well and it seems that they (so far) have no solution for this. If anyone has tried a workaround, we would be interested to hear the solution.
And please note that the solution in here is not working in Opera Mobile 10. I have not tried it in the proposed 9.X version.

I found it myself. And here is how to do it.
Have a hidden button in the form
input type="button"
id='myHiddenButton' visible='false'
onclick="javascript:doFocus();"
width='1px' style="display:none"
Have a javascript to get fired on the click event of the hidden button.
function doFocus() {
var focusElementId = "MyTextBox"
var textBox = document.getElementById(focusElementId);
textBox.focus();
}
Have the button clicked using a javascript at the end of the document
function clickButton() {
document.getElementById('myHiddenButton').click();
}
setTimeout("clickButton()", 100);

javascript textarea: what was typed/pasted, and where?

How do you find out what the user typed or pasted into a textarea? For example, if they typed in B (or β) at index 1, or if they pasted hello world\n at index 23. I've searched a fair bit but can't find anything. Here's what I have so far, uses jQuery:
$("textarea").keydown(function(evt){
var index= getCaret(this); // this.selectionStart doesn't work in IE
var key = evt.keyCode; // Wrong.
}
See this question for getCaret. The problem with event.keyCode is non-english keyboard layouts. I'm entirely stuck as far pasting is concerned.
If possible, I'd like to know the values before the textarea is changed - that is, from within the keydown event. I'm not sure if this can be done for pasting.
(Deletion is easier - detect keyCode==8 for backspace and keyCode==46 for del. If selection.length > 0, then the selection is removed; otherwise the character before or after is removed. In theory. There's also the case of pasting on top of a selection.)
Anything that gets any part of this closer to working in any browser is greatly appreciated. That is, how do you know:
the unicode string value of the typed character?
when a paste occurred?
what the text content of the paste is?

I'm not quite sure what your ultimate goal is here, so it's difficult to advise. However, here's some information:
When the user types a character, getting what they typed is easy enough using the keypress event and (assuming your event object is stored in a a variable called evt) using String.fromCharCode(evt.keyCode || evt.which).
For pasting, things are a bit trickier. The simplest thing would be to detect the paste before it has happened, store the textarea's value and after a very short time (using window.setTimeout) compare the new value with the old. As for detecting the paste, a lot of browsers now have the paste event: IE since version 5, Firefox since version 3 and WebKit browsers for a while (not sure exactly when), so you can use that for those browsers. As a fallback for other browsers you could detect Ctrl-V and Shift-Insert in a keydown event handler, though this is by no means foolproof since it won't fire when the user pastes using the Edit menu or the context menu in their browser.