I have a small question.
I want to check inputs after the blur event. A ajax-request should start an count something. So I don't want to check if the user is doing something in the input only after they finished doing something, but what if they focus the input and the users next click is to close the browser window?
Is the blur event is still firing?
Related
I'm trying to dismiss the keyboard via JS in response to a button press, but I'm not having any luck.
Setup:
I have a textarea with accept and cancel buttons tied to it.
Upon clicking the cancel button, my view object will call textAreaElement.blur().
It will then remove the accept and cancel buttons.
Expected:
Field loses focus (visually and otherwise).
Keyboard is dismissed.
Actual:
Field appears to lose focus (visually, no cursor is displayed), and programmatically.
Keyboard is still presented.
I've already tried the usual Google but they all seem to think that calling blur on the focused element should be sufficient. One user even suggested calling $('input').blur() to ensure that all fields were blurred, but that didn't seem to make a difference.
... and I just figured out why this was happening.
I mentioned that I was removing the Accept and Cancel buttons for this field. Specifically the following was taking place:
Call textAreaElement.blur().
Animate the buttons disappearing.
Upon completion of the animation, buttons.remove().
When the Cancel button received the click, it gained focus (the keyboard remained active). When the Cancel button was subsequently removed in the animation completion callback, focus was applied to the previous focusable element, which is the textarea.
So I had the effect of doing:
textarea.blur() # Already doesn't have focus.
buttons.remove() # Removes buttons, applies their focus back to the textarea.
The solution was to instead:
Animate the buttons disappearing.
Wait for completion of the animation, buttons.remove().
Call textAreaElement.blur().
Is there any way to "disable" focus of an element (textarea, input, contentEditable iframe)?
I know the blur function takes away the focus, but the user can just go back and focus it again.
I'm asking this because there will be a point in my site where a sort of a prompt (inside the page) will ask for something. At this moment, I want to block the focus of all textareas and inputs in the page, and allow it again when the user press "Cancel" or "Ok".
Thank you very much!
To prevent the user from focusing an textarea or input element, you can disable it:
$("#yourControlId").prop("disabled", true);
I'm not sure about a contentEditable iFrame
Native iOS apps contain "clear buttons" in input fields. They clear the text while maintaining field focus.
I am developing a web app targeted specifically at iOS devices, and not having any luck emulating the behavior. If I overlay another element with a click event to clear & refocus the input, the iPad ignores the call to focus because it begins hiding the keyboard the instant the blur event fires on the input (before the click event). Therefore the user must manually re-focus the field after clicking the clear icon to get back the keyboard.
Is there any way to grab a touch event on the overlay image/icon without the soft keyboard deciding to vanish, or a better way to do this?
daxelrod's 2nd comment above led me to the solution: Trap the mousedown event on the clear icon, stop it, and clear the input. Thereby a "click" never occurs, and the input does not lose focus.
I thought that blur() fired at the browser level before any of the mouse events (down, up, click) did, so I didn't think to try it. Glad to see I was wrong!
In Mootools flavored JS:
document.id('inputClearImage').addEvent('mousedown', function (e) {
e.stop();
document.id('input').set('value', '');
});
I need to determine what caused a focus event.
Ideally, I want to differentiate between a click, a tab/keyboard input, and a manual (via code) trigger.
How can I do this?
I'm looking at the event object, but I'm not seeing anything too useful.
If the focus comes from a $x.focus() call, then the event won't have an originalEvent property because there was no event from the browser so:
if(ev.hasOwnProperty('originalEvent')) {
// Focus event was manually triggered.
}
To differentiate between keyboard and mouse based focus events, you could try binding a keydown handler to everything else to detect a Tab or Shift-Tab but that would be a gross hack and probably not reliable; for example, on an iPad, you don't hit Tab to move to the next field, you hit Next or Previous in the popup keyboard to move around and those may not register as key presses at all.
There's a similar question about click events that might be of interest as well:
In jQuery, how can I tell between a programmatic and user click?
As you note in the comments, you could trap click events to detect a mouse-based focus change and set a flag somewhere to remember it. Then you'd have this:
If there is no originalEvent in the jQuery event then the focus change was triggered manually (i.e. $x.focus() or similar).
If the click handler flag is set then the focus change came from a mouse action.
Otherwise the focus change came from a keyboard event.
You'd have to be careful that your click and focus events came in the right order and you'd need to make sure the flag was cleared when you're done with it. This might not be bullet proof but maybe it doesn't need to be.
My page should make notification sounds only when the window is in the background. I can track the window.onfocus and window.onblur events to notice when the focus state changes. However, I don't know whether the window will load focused or not, since it might load in a background tab, for instance.
How do I decide whether to play sounds or not before I get an onfocus/onblur event?
Couldn't you just assume it's loaded blurred, and then change the status to focused as soon as you receive any type of event (keydown/mousemove)?
The onfocus event should be triggered when the page is initially opened (in the foreground). At least it is in FF3/IE8.
So you could have sounds on initially, turn them off when onfocus is triggered, and turn them back on when onblur is triggered.