Why isn't backspace being detected using jQuery keypress event?
$("#field").keypress(function(event){alert(event.which);});
Try using keydownand keyupfunctions instead for IE.
Javascript e.keyCode doesn't catch Backspace/Del in IE
The "keypress" event is (in its original IE form, and in Safari/Chrome) about an actual character being added to a text field. The backspace key clearly does not add a new character to the field value, so it causes no keypress event.
Firefox and Opera are a little more willy-nilly about generating typing events.
PPK (quirksmode) considers the IE and Webkit behaviors to be the sensible ones, and I pretty much agree.
The onKeyUp alone will do all the keyboard key detection in chrome..
Related
I'm trying to block all input on an html text field with jQuery. The following solution works on desktop browsers:
that.input.keydown(function (e) {
e.preventDefault();
e.stopPropagation();
e.stopImmediatePropagation();
return false;
});
However, while it blocks regular input it fails to block backspace on Android (Chrome). I've also tried blocking the keyup and keypress events, but that didn't help. I don't want to set the readonly attribute, because I intend to allow the input in certain situations.
Is there any clean solution for this? Thanks in advance!
The reality is that android keyboards are not keyboards. When a text field is opened in android the text-field-owner application and the keyboard application, speaking simply, come to share a resource which is the text field contents. The keyboard app receives the entire contents of the text field and then edits - including deletions - are made locally and pushed to the app via calls like DeleteSurroundingText (for simple deletions of non-text content i.e. whitespace) or setComposingRegion/setComposingText for changes to words. This means that autocorrect can work on already-existing words.
Some android keyboards generate keypress events which reach Chrome, some do not. Sometimes it makes no sense to generate keypress events - if a word is autocorrected what keypresses should be sent?
As you are looking for the keyboard and cursor to be displayed but the field to remain uneditable until later I would suggest you implement some sort of onChange/Revert loop.
Detect all changes to a <input type="text"> (immediately) using JQuery
Apparently android keyboards have a strange bug with the keyboard so instead of attaching to the keydown event maybe try the oninput event.
I found more info on this issue here Capture keys typed on android virtual keyboard using javascript
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`~!##$%^&*()_+=\\|/'";:,<.>?\[\]{}]
I'm not even sure if this is possible, so apologies if it's a stupid question.
I've set up an keyup callback through jQuery to run a function when a user types in an input box. It works fine for English.
However when inputting text in Japanese/Korean/Chinese, the function isn't called until the user confirms their text.
Is it possible to detect that they've started typing, and access their as-yet unfinished text?
I'm thinking maybe it's an OS-level thing so Javascript doesn't have access to it.
Edit: I just realised that this works in Chrome and Safari, but not in Firefox (not had a chance to try it on Windows yet). So Chrome calls keyup and it's possible to get the text. But I'm still having the above problem in Firefox.
The compositionstart, compositionupdate and compositionend events might be helpful.
They help you detect when IME input is being used.
For example, consider using an IME to type か (ka) in Japanese.
The following events (in the order shown) would be fired:
k (IME visible) keydown, compositionstart, compositionupdate, compositionend, input
a (IME visible), compositionstart, compositionupdate, compositionend, input
enter (IME closed) keydown, input
Notice that the compositon events are only fired when the IME is visible (before enter is pressed). Also notice that the keypress event is not fired. This is only fired for non-IME input.
To access the user's unfinished text, you can use the data property of the event.
$('#input').on('compositionupdate', function(e) {
console.log(e.data);
});
For more info see MDN: compositionstart, compositionupdate, compositionend, InputEvent.
This is a known issue in Firefox, and what browsers should be doing isn't clear.
A possible method for working around this problem is demonstrated here, where the text field is polled for changes to the text (rather than relying on events).
I'm not asking this because I need a work-a-around. I have one that works fine, but I want to know WHY it doesn't. Is this bug in Javascript (or JQuery because I was using the JQuery .keypress handler) or is there a specific reason why this is so?
The keypress event is designed for handling a character typed by the user rather than detecting keyboard activity and the delete and backspace keys do not generate characters. Some browsers blur this line somewhat but the general principle is that the keyup and keydown events are there to detect any key being pressed and telling you about which key it is while keypress is for detecting an actual character being typed.
The short answer is that the onkeypress event is not fired for all key types in all browsers. Check the manual for your browser.
Why?
Probably not a comprehensive answer, but consider Shift, when it goes down and when it comes up relative to other keys is significant. And different keyboard hardware has different key rollover characteristics which you might want to know about in detail.
I am implementing a special behaviour for the Enter key. The problem is my ASP.net library generates a readonly field; and when users tab into this field (tabbing into it is meaningful; so I want that behaviour) and press Enter to submit the form, it won't submit because it's a readonly field.
I wrote a workaround that hooks up your ordinary onkeypress=checkEnter, but IE6 will still not fire this event; Firefox will.
Whan can I do to detect an Enter on an IE6 readonly field?
Thanks!
For some reason IE6 won't detect pressing ENTER on the keypress event. It does however detect ENTER on the keydown and keyup events. Try the onkeyup=checkEnter instead of onkeypress. I just tested that and it works.
EDIT: According to this quirksmode article, Keypress fires when actual characters are being inserted. keyup/keydown fire on all keys. However, this behavior is different in FF and IE8.