I have a problem with catching event when user selects chinese symbols from drop-down that appears below textbox using mouse. If I select it using numbers or using spacebar, the onKeyUp event is triggered. But when I select right symbols from dropdown, it doesn't trigger any event.
GWT surfaces events that the browser dispatches, it doesn't do anything fancy for keyboard events (this is too much of a mess; higher-level events could be possible, but definitely not trying to normalize browser behaviors by synthesizing or suppressing low-level events). That means that if you don't receive a KeyUpEvent here, that's because the browser doesn't dispatches one.
See http://www.w3.org/TR/uievents/#events-composition-event-key-events which says that:
During the composition session, all keydown and keyup events MAY be suppressed.
Unfortunately, GWT doesn't expose the more recent and higher-level input event: https://developer.mozilla.org/en-US/docs/Web/Events/input (note that it still wouldn't work in old IEs, basic support only comes in IE9 according to the compatibility table at the end of that page)
Related
Is there a way to programmatically (using JS) start a keyboard event flow on an input[type=text] or textarea?
I mean that I want to make the element write a character as if the user has used the keyboard to do it. Meaning, it will consider the caret position, text selection, overwrite\insert state, CAPS-LOCK state, and so on.
Existing solutions (and questions) I've found don't give me that result, but just trigger a keydown or some other keyboard event on that element. I want to do something like:
document.getElementById('input').pressKey('e');
The solution has to be cross-browser (Firefox, Chrome and IE8+), and should not contain external plugins such as Adobe Flash - only things that can be sent with a web page.
Since I'm searching for an answer for a while now and I'm still without any clue, I'll just describe my actual problem:
I need to build up automated touch/mouse gestures (tap,drag,pinch...) which I can fire on a webpage in order to test touch frameworks and their performance. Thus I want to trigger "global" touch/mouse events on a webpage with JavaScript without dispatching them from a specific element.
Does anyone know how I could achieve this or how these events are delegated in general?
If you need this just for the sake of emulating mobile touch actions on your browser, Chrome already has a tool for that. Check out Mobile Emulation.
I'd like to have two (or even more) identical html forms on my website.
For example, one - at the top, and another - at the bottom of the page.
What i want is for them to have exactly the same content at any given time. If user changes a value in one of them, all the rest are updated.
Is there a better way to synchronize then javascript onchange/onkeyup events?
onchange fires only after element loses focus.
onkeyup is not perfect too. It wastes a lot of cpu on long text copying and won't fire if element lost focus between onkeydown and onkeyup events.
Update: I just learned that HTML5 has a more appropriate event for this, oninput, but of course it doesn't work in older browsers. oninput will detect any kind of text change, including Paste, Cut, and Delete from the right-click menu. So the best option may be to check if the browser supports oninput (e.g. by using the function recommended here), falling back to the below method if not. On older versions of IE, onpropertychange can be used to simulate oninput.
I decided to change my answer, based on how KnockoutJS accomplishes this. From this page in the Knockout docs:
"afterkeydown" - updates your view model as soon as the user begins typing a
character. This works by catching the browser’s keydown event and handling the event
asynchronously.
Of these options, "afterkeydown" is the best choice if you want to keep your view model
updated in real-time.
It accomplishes the asynchronous behavior by using setTimeout with a time value of zero. Other than that, it appears to be just like a regular keydown event handler.
Here's a simple example, using jQuery, which I believe behaves equivalently to Knockout's "afterkeydown" event:
$('#email').keydown(function() {
setTimeout( $.proxy(handler, this), 0);
});
function handler() {
console.log( this.value );
}
Note:
This will not catch right-click paste events and drag-and-drop events. If you want to update the text on those events too, simply listen for them in the same manner as keydown, e.g.:
$('#email').on('keydown paste drop', function() {
setTimeout( $.proxy(handler, this), 0);
});
Like keydown, paste and drop also need the setTimeout in order to update with the latest value of the text.
Original answer:
onkeyup is probably the way to go, but you raise a good point about it not firing if the element loses focus between keydown and keyup. Based on this answer, I'm pretty sure the solution would be to listen for the keyup event on a container element (or on the body, although in this case it would probably make the most sense to bind it to the <form> element).
As to CPU usage on paste, you could try canceling the event unless a certain amount of time has passed (say 50 ms)...hopefully that will be sufficient. If not, you could look at how some of the popular 2-way data-binding frameworks handle this...most of the ones I've seen use onkeyup.
If I use xss, what's the difference between typing in ALERT('DSSA');, or just paste it to a search textfield? In a site, typing works, and makes the alert, but if I just paste it, than it doesn't. To prevent the question, I don't want to hack any site, I'm just interested in network security.
thanks for the answer
This will be because the programmer who built the website is lazy and hasn't listened for the onpaste event.
Typing fires the onkeydown, onkeypress and onkeyup events, and are the standard events to consider when watching for user input.
It would seem those are the only events the programmer has listened for (which makes this irrelevant of network security).
If this is not the case, then he'll be using two different event handlers for the events; one which escapes the input, and in the other he's forgotten.
I may not have understood the question properly.
Typing triggers keyUp, keyDown and keyPress events on the element. If the codes are programmed to capture them only, then only those events will be captured.
Pasting can be done using keyboards, mouse and browser options. So this depends on which events you are listening too. There is a separate event called onpaste which will ease everything.
What I mean is, lets say my code is written to capture the pasting my pressing "Ctrl" + "v" only, but if mouse and browser options are used to paste on the
element, then it is configured to capture mouse events also, it cannot
be captured.
We have a request to use a select element's onchange to trigger a move to a new page.
In the past, web accessibility literature I've read has generally advised against doing this. This was on the grounds that it breaks user expectation, and browsers (particularly IE < 6) fired the change event even when moving through options with the keyboard, making it impossible for keyboard-only users to make a selection.
IE6+ and all other more modern browsers I have tested fire the select onchange when an option is actually selected by mouse or enter key. Analytics for the application in question show that earlier IE browsers are essentially eradicated (< 0.01%)
Given that our users will be able to operate these select elements properly with a keyboard only, should this feature still be considered an impediment to accessibility? This behavior seems so common nowadays that I wonder also if it really still does break user expectation in a meaningful way?
EDIT: IE behaves differently if the select is focused with the mouse or keyboard. When focused with the mouse, keyboarding through options does not fire onchange but when tabbing to focus it via keyboard, the onchange does fire when arrowing through.
Using the onchange event of the select element to navigate between pages can definitely pose an accessibility problem for keyboard-only users.
There is at least one method of creating accessible select elements with onchange handlers and it has been on the interwebs since 2004!
Direct link to the Accessible Select code.
I agree with you that this type of functionality is very common. However, most sites use links instead of a <select> to achieve the effect (if I'm not mistaken). I.E. it's the standard (pun intended).