We Keep Coding

Clearing the value of a text box after the enter key has been pressed

I've created a site/game for school with a text box. It looks a little like Quizlet (https://quizlet.com).
When the users presses the enter key, the input should be cleared. The problem is: On the computer, it works just fine but on a phone, it leaves an empty line. So the word checker always counts it wrong unless the player removes it with the backspace. Is there a way to remove the enter on a phone? Because I'm having a lot of trouble with it (especially because it's kind of necessary that it works on a phone).
// The code I used a year ago to
resetInput();
function resetInput() {
document.getElementById("input").value = ""; //
document.getElementById("opmerking").innerHTML = "TextBalk geupdate!";
}
Edit
I found the solution, the problem was that I called an 'onkeypress' event, which can fire before the key is released, meaning the input is cleared, and after that, an enter is placed. I fixed it by using the onkeyup event, and canceling this event when the pressed key was the enter key.

The solution was the timing in the events.
I called an 'onkeypress' event, which fires before the key is released, meaning the input is cleared, and after that, an enter is placed. I fixed it by using the onkeyup event, and canceling this event when the pressed key was the enter key.

Angular: "tab" keycode event not firing

I have a form field with a handler that I want to trigger after the user deliberately accepts the value with either return/enter or tabs to the next field. I can't use onBlur in this case, since it of course triggers if the user or system blur the field. I only want it on a keyup.
So I have this. I had the enter first, and it works great. But the keycode==9 does not trigger the handler. The focus merely moves to the next field.
ng-keyup="($event.keyCode == 13 ||
$event.keyCode == 9)
&& packages.submitNumber('add', packages.addTrackingNumber)"
Is there a way to have this fire on enter OR tab?

Tab button in html is tabulating to the next focusable element (buttons, inputs etc.). So when you keydown tab button keyup is happening on the next focusable.
To avoid this you can try to use ng-keydown.
See working example

Android keyboard keeps appearing after closed

I have a textarea in my html. When the user taps on it, the keyboard properly pops up. After hitting the keyboard close button, the keyboard keeps appearing when tapping elsewhere on the screen. Is there a way to have keyboard only appear on input taps?

The following bit of jquery code does the trick:
$(window).bind('touchstart', function (e) {
if (!$(e.target).is(':input')) {
$(':input').blur();
}
});
Basically, I catch every tap; if the target is not an input field, blur all the input fields, which in effect hides the silly keyboard.

Keyup event for text input box being capture by Google Chrome address bar

I am using the keyup event to fire the same event as clicking on the search button when a user presses the return key. When the search button is clicked it uses an Ajax request to load search results on the page.
The call works fine, but the keyup event is being captured when I press the return button in the address bar in google chrome after previously having focus on the input box, e.g. if the user types in a search query without pressing return, and instead goes to a new webpage using the Google Chrome address bar, when they press return on the address bar the search in my page is being submitted at the same time as the keyup event is being trigger even though the page, and certainly the input box, should no longer have focus.
JavaScript
$("#search-box").on("keyup", function(event) {
if(event.keyCode == 13){
$("#search-submit-btn").click();
}
});
HTML
<div class="input-append"/>
<input id="search-box" type="text" />
<button class="btn" id="search-submit-btn">Search</button>
</div>
I'm also using Twitter bootstrap to style the Input box, but I don't think this is causing the problem.
I've tested this page in Firefox and Safari without any issue. Does Google Chrome have a problem with the keyup event/is this a know issue? I'm struggling to find any information on the issue.
EDIT
I think I've solved my issue by using keydown instead of keyup. I've also added in a check if the element is still focused, but I don't think this makes a difference, since it still has the same affect with keyup.
$("#search-box").on("keydown", function(event) {
if($("#search-box").is(":focus")){
if(event.keyCode == 13){
$("#search-submit-btn").click();
}
}
});
This appears to be an okay solution for me, but it doesn't explain why keyup behaves so strangely in Google Chrome though. If anyone has anymore information about why keyup is this way in Google Chrome or if I am just doing something wrong, I'd be very interested to hear.

Override default Tab Behavior to keep focus on browser form

I'm building my first application where I have to have compliance with keyboard navigation for accessibility reasons.
My problem has to do jquery-ui modal dialog boxes. If the user presses tab on the last control of the dialog (cancel button for this app), focus goes outside of the dialog box. Or presses shift-tab on the first control in the dialog box.
When the user does this, it isn't always possible to tab back into dialog box. IE8 and FF8 behave somewhat differently in this respect. I've tried to capture the tab key with the following event handler -
lastButton.keydown(function (e) {
if (e.which === TAB_KEY_CODE) {
e.stopPropagation();
$(this).focus();
}
});
But this doesn't work as it appears the browser processes the key press after jquery is done.
Two questions -
For Accessibility compliance, do I even have to worry about this? Although, for usability reasons, I think that I should.
Is there a way to make this work?

My problem has to do jquery-ui modal dialog boxes. If the user presses tab on the last control of the dialog (cancel button for this app), focus goes outside of the dialog box. Or presses shift-tab on the first control in the dialog box.
... and then tabbing occurs below the modal box, under a grey semi-transparent layer with scrollbar jumping from bottom to top after a few keypresses? Yes, this is a concern for sighted users who use the keyboard to browse and won't know how to go back to the modal box without pressing Tab a hundred times. Blind people won't even know the modal box is still displayed (they still can see/hear the entire DOM with their screen reader!) and that the page/script is waiting for a submit or cancel decision so it's also a concern for them.
An example done right is shown at http://hanshillen.github.com/jqtest/#goto_dialog (click on Dialog tab, direct link with anchor doesn't work :/ ). It'll tab forever inside the modal box till you click on Close or OK and will put you back on the focused element that triggered the modal box (I think it should focus the next focusable element after leaving the modal box but nevermind, this isn't the biggest accessibility problem here).
This serie of scripts is based on jQueryUI and are highly improved for keyboard and ARIA support and any accessibility problem that could exist in the original scripts. Highly recommended! (I tried to mix jQuery UI original scripts and these ones but didn't manage to get anything working, though you don't need to do so: these scripts work fine by themselves)

Maybe you should prevent the default action with preventDefault() instead of stopping the propagation and use keypress instead of keydown.
In this way there should be no need to regain focus.
Stopping the propagation doesn't work because it just prevent the event from bubbling up. You could think about using stopImmediatePropagation() but i think that changing input on the pression of the tab can't be stopped that way and preventDefault() is more correct.
lastButton.keypress(function (e) {
if (e.which === TAB_KEY_CODE) {
e.preventDefault();
}
});
fiddle here: http://jsfiddle.net/jfRzM/

Im a little late to the party, but I found I had to call preventDefault in the other keyboard events as well.
ex) I was setting the focus in the keyup event. But the browser was still doing its thing in either keydown or keypress. So I had something like this (I used JQuery/Typescript, but the idea should translate to about anything):
elem.keyup(this.onDialogKeyPress);
elem.keydown(this.onDialogPressPreventDefault);
elem.keypress(this.onDialogPressPreventDefault);
...
private onDialogPressPreventDefault = (e: KeyboardEvent) => {
const keys = [9, 27];
if (keys.includes(e.which)) {
e.preventDefault();
return false;
}
}
private onDialogKeyPress = (e: KeyboardEvent) => {
// Tab
if (e.which == 9) {
e.preventDefault();
// Do tab stuff
return false;
}
// Esc
else if (e.which == 27) {
e.preventDefault();
// Do Esc stuff
return false;
}
}