Probably going to be something really obvious that I can't find again. But any help, as always, is appreciated.
My javascript error messages and focus settings work fine with all of the validation functions on submit, but I can't get the field to take focus with the onblur validations. The error message correctly appears but the focus is going to the next field in the form.
Here's my code for the field in question Javascript first:
function validatexxxx()
{
var e = document.getElementById('xxxxNumber');
//check to see if the xxxx number is already in use.
for (i = 0; i < xxxxArray.length;i++) {
if (e.value == xxxxArray[i]) {
alert("That xxxx Number is already in use!");
e.focus();
return false;
}//end if e.value = xxxxarray
}//end for loop
var eText = e.value;
if (eText.length >= 15) {
alert("xxxx Number must be less than 15 characters long!");
e.focus();
return false;
}
return true;
}
And the html where the input is:
<tr><td>xxxx No.: </td><td><input type="textbox" id="xxxxNumber"
name="xxxxNumber" onblur="return validatexxxx();"/> </td> </tr>
It's the alert() that's causing the focus to go away. After the popup is displayed, you're setting the focus. But as user needs to click OK in the appeared popup window, the focus is lost.
Trying to force focus from a "blur" handler is inherently problematic. Try this: wrap you calls to .focus() in a timeout handler. That'll let the "blur" event complete before the attempt to set focus:
setTimeout(function() { e.focus(); }, 1);
Also, alert() can be problematic too, especially in Safari. That browser has (or had, in the past; I haven't tried lately) a tendency to imagine that the appearance of the "alert" window means that the main browser window has lost focus. After that, Safari will completely ignore any calls to .focus(). Your interface would look better with a custom "dialog" scheme, or some other way of reporting validation errors.
Try to put it in a closure like this.
e.focus(function() {
alert("xxxx Number must be less than 15 characters long!");
});
Related
I'm trying to limit the user's ability to click on an object to a certain time limit. I looked around and found that apparently, setTimeout() is the correct function to use for this type of thing. I've applied the function to my code, but its not working. I'm thinking/know now that the problem is that the setTimeout in my code isn't limiting the actual click event, which I need to do. Here is a snippet of my click code:
function clickRun(event) {
var $objectVersion = correspondingObject(event.target.id);
if (isAnyVisible() == false) { // none open
$objectVersion.makeVisible();
} else if (isAnyVisible() && $objectVersion.isVisible()) { //click already open div
$objectVersion.makeInvisible();
} else if (isAnyVisible() && $objectVersion.isVisible()==false) { //different div open
searchAndDestroy();
$objectVersion.delay(600).makeVisible();
};
};
$('.ChartLink').click(function(event) {
setTimeout(clickRun(event),5000);
});
I've also created a JSFiddle to represent what I'm talking about: http://jsfiddle.net/FHC7s/
Is there a way to achieve limiting the actual click detection on the page?
I think the easiest way to do it is to keep track of the time of the previous click and if the current click is too soon after that, then don't do anything:
onClick = function(){
if(new Date().getTime() - lastCheck < MIN_CLICK_SPACING) return;
}
Have a look at this JSFiddle, I've set it up so you can have the button disable itself for time duration after detecting a click. Just make sure to remember how your closures are operating with your setTimeouts.
Your code contains an error... your line should be
setTimeout(function(){clickRun(event)},5000);
but even then I don't think that's exactly what you're looking for; that code will "delay" the click by 5 seconds, not actually prevent more clicks. If your true intent is to ignore all clicks after a certain amount of time, then I would go with mowwalker's answer; there's no way to stop the clicks, but you can check to see if you should honor them or not.
I've been experiencing an odd problem with IE10 when redirecting the page on an 'oninput' event (with no equivalent issue when using Chrome). I've produced the most pared-down version of the code that still exhibits the problem, as follows:
<html>
<head>
<script type="text/javascript">
function onChangeInputText()
{
window.location.href = "oninput_problem.html"; // Back to this page.
}
</script>
</head>
<body>
<input type="text"
oninput="onChangeInputText()"
value="£"
/>
</body>
</html>
On my Windows 7 PC using IE10, this code when browsed to (either by double clicking or via Apache) repeatedly redirects as if the act of initialising the value of the input text box itself is generating an immediate 'oninput' event. However, when I change the initial input text box value from the '£' symbol to a letter 'A', the repeated redirection doesn't occur.
I first noticed this problem as part of a project I'm working on. In that case, the user's input should cause a delayed page refresh, which began repeatedly redirecting when I entered a '£' symbol. As I say, the above code is the most pared-down version I produced in trying to track what was causing the issue.
Does anyone else experience this using IE10? If so, can anyone explain why IE10 is behaving this way?
I've found the following that appears to indicate that this may be a bug in IE10:
social.msdn.microsoft.com: Event oninput triggered on page load
Also, there's a follow-up bug report (within the page linked to above):
connect.microsoft.com: onInput event fires on loading the page when input #value is non-ASCII
EDITED TO ADD: At the bottom of the page pointed to by the second link, there's what would seem to be an unhelpful reply from Microsoft stating that they are unable to reproduce the bug described, so it may be a while before the issue is fixed...
There's anoter bug report which is still open :
http://connect.microsoft.com/IE/feedback/de...
For anyone who might encounter this, you can use this "class" as an alternative to the onInput event.
const getFieldWatcherInstance = (function(watchedElement, onElementValueChange){
let intervalReference = null;
let lastValue = null;
if(!watchedElement instanceof Element) return new Error('watchedElement is not an HTML Element');
if(typeof onElementValueChange !== 'function') return new Error('onElementValueChange is not a function');
return {
toggleFieldWatching : function(){
if(intervalReference){
clearInterval(intervalReference);
intervalReference = null;
}
else{
intervalReference = setInterval(function(){
const currentValue = watchedElement.value;
if(lastValue !== currentValue){
onElementValueChange(currentValue);
lastValue = currentValue;
}
}, 100);
}
}
};
});
Set it up like this:
const myInputChangeWatcher = getFieldWatcherInstance(<**insert real element reference here**>, function(newValue){
console.log('The new value is: ' + newValue);
});
call myInputChangeWatcher.toggleFieldWatching() in the onfocus and onblur events of the input
This is a odd behavior that seems to only happen in Chrome and with JQuery UI. When entering characters into a password field at first everything functions correctly. However, if you attempt to backspace to the last letter in the input, the browser locks up all client side operations. Also, if you try and highlight the characters entered and backspace the client side operations freeze.
Just reaching out to see if anyone has encountered this same issue, and how they resolved it.
In order to experience the issue, we have the dialog auto opening on 2+ unique page home views. Here is a listings page so it can be triggered, I apologize for the inconvenience but I can't remove the counter.
Page: http://www.christineleeteam.com/area/eagleharbor
I had the same problem but cache clearing didn't help. I'm sure it isn't a jquery ui bug.
Here is my solution:
$('input[type="password"]').on('keydown', function(event){
if (event.which == 8) { //backspace event
event.preventDefault();
$(this).val('');
}
});
This code is clearing the whole password field on one backspace event.
We encountered the same issue, and used Benkod's solution.
We improved it a little to also handle cases where the password text is deleted with the delete key (and not backspace).
Another case is when all the text in the control is selected and new text is typed to replace it.
Here is the script we used:
Sys.Application.add_load(function() {
$('input[type=password]').keydown(function(event) {
var isAllTextSelected = this.value.slice(this.selectionStart, this.selectionEnd) == this.value;
var isLastChar = $(this).val().length == 1;
if (isAllTextSelected && $(this).val().length > 0) {
$(this).val('');
}
if ((event.which == 8 || event.which == 46) && (isLastChar || isAllTextSelected)) { //backspace event
event.preventDefault();
$(this).val('');
}
});
});
Same problem here (FWIW, I'm using Twitter Bootstrap, but the issue was the same). It looks like it's caused by having a lot of content preceding the input. Placing the input higher--above the bulk of other content--did the trick for me. A work around, but better than nothing.
In IOS5 on the iPad, iPad2 etc. iBooks accepted <input type="color"> as a way to prompt the keyboard to display when you clicked on an input field, to say, type in the answer to a question. I've just recently updated to IOS6, and this workaround no longer seems to be working. I tried using the JavaScript I found here - http://www.linkedin.com/groups/How-Show-iPads-Keyboard-when-3877009.S.84287009
<script type="text/javascript">
function iPadTouchHandler(event) {
var type = "",
button = 0; /*left*/
if (event.touches.length > 1)
return;
switch (event.type) {
case "touchstart":
// OLD: On iPad2 clicking on a text input field did not show the keyboard
// if ($(event.changedTouches[0].target).is("select")) {
// NEW: Now on iPad2 the touchstart-Event on input fields is ignored and everything works fine
// change my by Roland Caspers, Scheer Management
if ($(event.changedTouches[0].target).is("select") || $(event.changedTouches[0].target).is("input")) {
return;
}
iPadTouchStart(event); /*We need to trigger two events here to support one touch drag and drop*/
event.preventDefault();
return false;
break;
</script>
However this code seems to be outdated and relevant to IOS5. I know of a workaround, which is to put the page with the input into an iFrame, in that case you can just use <input type="text">, however I'd prefer to stay away from iFrames as they tend to move the content around depending on where the input box is. Any thoughts as to other possible solutions or workarounds? Tyvm :)
I am also Facing the same issue on iOS6 for , the same is working perfectly on the <iframe> tag. But it omits the images & style and etc.
Review the code "http://www.linkedin.com/groups/How-Show-iPads-Keyboard-when-3877009.S.84287009", I feel some thing has to modify on below condition:
($(event.changedTouches[0].target).is("select") || $(event.changedTouches[0].target).is("input"))
I'd be great if anyone provide the earlier response.
Thanks
I struggled with this same problem in iBooks on iOS 7. The tricky part was, that iBooks probably makes all text input fields disabled by default. We are using prototype.js, so here is my solution written for prototype:
$('my-input-field-id').observe('touchstart', function(event) {
var element = event.element();
if (element.disabled)
element.disabled = false;
element.focus();
event.stop();
});
So just listen for the 'touchstart' event on the input field and enable and focus the field when touched. It works for ordinary text fields (<input type="text">). Simple :-).
Note: A possible solution needs only work in Firefox 3.0, my app doesn't allow access from IE! =)
I have a link that, when clicked, will display a lightbox to the user:
show lightbox
My problem is that when the lightbox is displayed, the focus remains on the link. So if the user presses the up or down keys, they end up scrolling the main document, not the lightbox that is displayed!
I've tried to set the focus to the lightbox element using code like this
function focus_on_lightbox() {
document.getElementById('lightbox_content').focus();
}
This works fine if I type it in the firebug console, but will not work if I include it at the end of the onclick snippet. It appears as though I can't change the focus away from the link from code executed inside the onclick event?
-- Update 1
I've tried something like this before
show lightbox
and I've modified function to add some debugging output, as follows
function focus_on_lightbox() {
console.log('hihi');
console.log(document.activeElement);
document.getElementById('lightbox_content').focus();
console.log(document.activeElement);
}
The output is as follows
hihi
<a onclick="closePopup();lightbox('apartment_detail','11619');focus_on_lightbox();return false;" href="#">
<a onclick="closePopup();lightbox('apartment_detail','11619');focus_on_lightbox();return false;" href="#">
So the focus before I did anything was on the link and after I tried to change the focus it still remained on the link?
Not sure if it matters, but I use ajax to load the lightbox, as follows
new Ajax.Updater(lightbox_content_id, url, {asynchronous:true, evalScripts:true, onLoading:show_lightbox_loading(), onComplete:focus_on_lightbox() });
I tried to set the focus after the ajax complete, but also, no luck.
What am I missing?
I've been trying to make a solution work that was suggested below by trying to set the focus, seeing if I succeeded by checking document.activeElement, if not, wait 100 milliseconds and try again. If I use the following function, it will work
function focus_on_lightbox() {
var seconds_waited = 0
pause(100);
var current_focus = document.activeElement
while (document.getElementById(lightbox_content_id) != current_focus && seconds_waited < 2000)
{
document.getElementById(lightbox_content_id).focus();
console.log(document.activeElement);
pause(100);
current_focus = document.activeElement
seconds_waited += 100;
}
}
However, if I remove the firebug debugging statment console.log, the function stops working!! I have no idea why this would be the case?? Why would outputting a variable to the firebug console affect weather focus is moved to the element or not? Does the console.log statement affect focus? perhaps by bringing the focus to the console debugging window?
I think your problem is calling your focus method after return false. your code should be like that :
<a href="#"
onclick="show_lightbox();focus_on_lightbox();return false;">
show lightbox
</a>
Here is the function that finally worked
function focus_on_lightbox(seconds) {
var seconds_waited
seconds_waited = seconds
document.getElementById(lightbox_content_id).focus();
seconds_waited += 100;
if (document.getElementById(lightbox_content_id) != document.activeElement && seconds_waited < 2000)
setTimeout("focus_on_lightbox(" + seconds_waited + ");", 100);
{
}
}
So why did console.log seem to affect setting the focus? Before I was using this function to pause between attempts of changing the focus.
function pause(milliseconds) {
var dt = new Date();
while ((new Date()) - dt <= milliseconds) { /* Do nothing */ }
}
This causes javascript to constantly be doing something and I think it wasn't giving the document time to render or update or something. The console.log seemed to break this lock and give the page a chance to change its focus.
When I changed approaches to using the timeout to pause between attempts, console.log was no longer needed!
Thanks bmoeskau for pointing me in the right direction.
In my experience, focus issues can sometimes be timing-related (e.g., focus() executes before the element is fully ready to be focused). I'm assuming that the lightbox markup is created dynamically when the show_lightbox function is called? If that's the case you could try adding a slight delay before attempting to focus to see if that's the issue, something like:
setTimeout("focus_on_lightbox();", 10);
Make the element focus itself. On the element's load event, set a timeout of a few ms and then call this.focus();
Else try jQuery.