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.
Related
Trying to focus a simple input text when page loads with Javascript events, my goal is to focus and open the virtual keyboard on mobile browsers but I've not gotten success.
My code looks like so simple as:
document.getElementById("anser-animation").focus();
document.getElementById("anser-animation").click();
I've tried on jQuery as well...
$('#answer-animation').focus();
$('#answer-animation').trigger('click');
On android input gets focus but not on iPhones. On both cases I don't get the keyboard intermediately on page loading. I'm not sure what's more I have to do.
To my knowledge. That is because Apple has decided to disable this functionality, when bind with $(document).ready(function (){});
What you could do (if target-page is reached via Ajax and/or if it's applicable in your case) is that when a button is pressed, i.e ("sign up") is trigger focus(); on the input field.
Like this:
$(".sign-up-button").click(function (){
$(".first_name").focus();
});
This is at least how I've solved it in the past, but if this won't work for you, then I'm sorry, but you're just out of luck, like so many of us. For now at least.
You have you do like this
$("#fname").trigger('focus');
I'm using the following jQuery plugin: http://willowsystems.github.io/jSignature/
I'm trying to do something very simple which is stopping page scrolling when the user's finger is inside a signature area (the page movement when writing a signature on the phone is excruciatingly bad to the point where you can't write your signature at all). I have tried the following which is not working in Firefox and I'm not sure why:
$('.signature').on('touchmove', function(e) {
e.preventDefault();
});
I have also tried this which isn't working either:
$(document).delegate('.signature', 'touchmove', false);
I've searched for hours and I can't seem to find anything that works. If anymore detail is required please let me know and I will happily append to the question.
Thank you very much for everyones help.
edit: I'm using the latest version of Firefox on the phone.
try to use the e.preventDefault() on the ontouchmove of the html element.
<div class="signature" ontouchmove="event.preventDefault();">
</div>
this example works for me:
http://jsbin.com/pulul/1/edit?html,css,output
Same problem in field on Android browser. Capturing signature gets dots instead of sig. So, testing in browser I see the focus is never lost from prior field when i click with mouse into jSignature. So, try something like this:
onblur="if(this.value.length>1) document.getElementById('CustomerSignature').focus()"
Welp, with that you'll see the onblur DOES NOT FIRE when you touch your jSignature but does fire when you touch your other fields. There ya go. Have not been able to reproduce the exact bug reported to me yet on the tablet; but I think the scroll is being sent to ANOTHER element.
So, fix is to force the focus to change to the jSignature. That's what I think.
For now, I fiddled around with the HTML so my last field is a select and use the onchange to set the focus to my jSig.
I have a textarea on a html page, on google chrome, well I don't know what version because the user interface is deviously hidden, but on chrome the onChange="code" event isn't firing but on Firefox 11.0 1.0 (according to help->about) it is firing. Then instead I start playing around with the events onkeydown="same_function()", onpaste="same_function()" and oninput="same_function()", in order to be absolutely sure to capture at least one event. But now the problem is that I'm getting too many events, and when I check the textarea_dom_object.value of the textarea after getting a keydown event the key that was pressed isn't included in the value that I'm reading; if I have "abc" in the textfield and I press 'd', that generates a keypressed, but I'm still getting only "abc", not "abcd".
Is there a compatible way, or at least a way that works on most browsers, to get an event every time a textarea changes, but preferably only one event? I don't like the kind of ugly code I would have to write if I had to first test if I've already listened to an event and so forth. All I want is one event each time the text in the textarea changes.
Here's the thing about why jQuery is so amazing. It understands the need to gracefully degrade the code between browsers that don't support newer functionality. JavaScript in and of itself does not offer this support stand alone. By enhancing JavaScript's core capabilities in using jQuery, you are generally going to be more successful with cross browser support.
That being said...
There are still plenty of scenarios where you need to identify what device/browser you're working with so that you can perform the expected operations.
The most important thing to remember is that there is no 100% cross-support library in existence.
you can do this. just make sure you give the textarea an id tag
$(document).ready(function(){
$('.addtitle').keyup(function(event) {
if(event.keyCode==13) {
}
});
});
in my case here, im firing the function on the enter key (like facebooks functions).
EDIT: also if you have more then one textarea on a page, you should do this:
$(document).ready(function(){
$('textarea[name=mynamevalue]').keyup(function(event) {
if(event.keyCode==13) {
}
});
});
I'm a little distraught at the current state of key capturing for web applications. It works great as long as you know your user is going to be typing in a specific place (e.g. an input field), but as soon as you want to do global shortcuts for an entire "application", it seems to fall apart.
I'm trying to find out if there is a better way to capture all the key events for a web page than the method I am currently using.
My current method is to use the JQuery Hotkeys plugin, bound to the document element, i.e.:
$(document).bind("keyup", "delete", function() {});
That works great for most purposes, but for example on Firefox, if the user happens to absentmindedly move their mouse over the navigation bar, the delete key will sometimes result in the user going "back", and the key is never received by the handler so that I can stop propagation.
Is there a different element I should be binding to? Is there a better plugin out there for this? Should I just avoid using any keys that are bound to things in common web browsers?
As more and more web applications look to mimic their desktop counterparts, it seems like this is a basic feature that web developers will increasingly require.
EDIT: I should point out that I am already using e.stopPropagation() and e.preventDefault(). The main problem seems to be that sometimes the event is never even passed to the bound function. I am basically wondering if anyone has figured out a "higher" element to bind to other than document. Or is there an alternative I have never even thought of? Embedding an invisible Flash element on the page and then passing all keys from that to JavaScript, for example (I don't think this would work).
I think, at this point, I am doing things the "standard, well-known way." I am trying to see if there is an outside-the-box way that isn't widely known that maybe someone on Stack Overflow knows about :-).
If you are making a sophisticated web-app with customized keyboard controls, the first thing you should do is alert the user that you are making a sophisticated web-app with customized keyboard controls. After that, tell them what the controls are and what they do.
Binding the keypress and keydown listeners to the document is the correct way to do it, but you have to remember to preventDefault and/or stopPropogation for keypresses that you want to override. Even if there is no default behavior, you will need to prevent them from cascading in case the user has rebound their default keyboard shortcuts.
Also, you will only be able to receive keyboard input when the page has focus.
When you say Delete I assume you mean the Backspace key as Delete generally referrs to the key next to Insert, Home, End, Page Up and Page Down.
Edit to add:
Be very careful about which keys you choose to override. If you're making an app to be used by people other than yourself, you have to worry about usability and accessibility. Overriding the Tab, Space and Enter keys is risky, especially for people using screen-readers. Make sure to test the site blind and fix any issues that may arise with traversing the page via the keyboard.
maybe you can use html-attribute ACCESSKEY and react onfocus.
i.e.:
<input type="text" size="40" value="somefield" accesskey="F">
i think u might need to add a tabindex to tags like <div>
<div id="foo" tabindex="1" accesskey="F">
You can't bind to events that happen where you have no control - e.g. the window chrome. The way most webapps deal with this is asking the user to confirm their decision to leave the page, using the onbeforeunload event:
window.onbeforeunload = function (e) {
var str = 'Are you sure you want to leave this page?';
e = e || window.event;
if (userHasSomeUnsavedWork) {
e.returnValue = str;
return str;
}
}
onbeforeunload - MDC
Absolutly non-tested but... try it on 'window' element.
One of the most recommended ways to listen for a change of a input text field is to bind that field to a key up event. That works fine in most cases. But there are cases where this is not working. In Firefox for example one has the option, when text is already selected, to delete it by using the context menu. And this doesn't fire a key up event. I haven't found any event that is fired for that text field when doing this.
Any suggestions how I can react on this (in pure Javascript or jQuery)?
See the oninput event, and my write up about it here.
oninput fires for all forms of text input - including cut, paste, undo, redo, clear, drag and drop and spelling corrections. It's a HTML 5 event which isn't supported in Internet Explorer 8 and lower (but it is in the latest IE 9 preview). However, Internet Explorer supports a proprietary event on all DOM objects - onpropertychange. This fires whenever the value of an input element changes.
I didn't notice you'd tagged with jquery — since you did, it's probably worth mentioning that I wrote a plugin to implement the oninput event cross browser. You can find it here.
The best way is to store the value on a focus event and recheck the value on a blur event. Listening to key events fires a lot of usually redundant processes. Most of the time, you are only interrested in a field value when the user is done inputting (or deleting) it.
This works cross browser, though delegating focus/blur can be an issue in some browsers. The easiest way is to apply blur/focus listeners to the element directly.
Only exceptions are implementations like autosuggest/complete and even then you might want to debounce key input so it only fires when the user idles for a few hundred miliseconds.