Stop Return/Enter Key Submit

[Dal]

Hi (New member today)

I need to stop my form from being submitted via the Return/Enter key.

When I use an attachEvent I get errors that this isnt a function. Can anyone correct me?

<script type="text/javascript">
//<![CDATA[

window.attachEvent("onkeydown", StopReturnKey);


function StopReturnKey(event)
{
    alert("HELLO"); //just testing at the moment.
    //if(event.keyCode == 13) return false; // I think this is what I need to do.
}

//]]>
</script>

Thanks
Dal

[Dal]

Forget about the above.

I really need to stop enter key at all costs but I still need submit to work on my various buttons.

IE seems to have no issue but FF3 just keeps submitting with enter, I cant find anything but old posts on google.

Anyone got a document.EnterKey = "off" suggestion???

Kind regards
Dal

[Jesdisciple]

You're on the right track.

Older versions of Firefox apparently use the 'which' property instead of 'keyCode,' but Firefox 3 (what I'm testing with) uses both. I was able to figure everything out except where to put the event handler; I tried the form-tag, but this page set me straight: You need one handler for each input element that the effect should apply to. Also, keydown is supposedly better than keypress; see Comment #19 at the above page.

<form><input type="text" onkeydown="return event.keyCode != 13 && event.which != 13;"><input type="submit" value="Submit"></form>

(Using input.onkeydown in JS might also work; try it!)

[jscheuer1]

This seems to work page wide, at least in limited testing:

<script type="text/javascript">
document.onkeydown = function(e){
e = e? e : window.event;
var k = e.keyCode? e.keyCode : e.which? e.which : null;
if (k == 13){
if (e.preventDefault)
e.preventDefault();
return false;
}
return true;
};
</script>

If you want to use the more up to date methods for adding the event:

<script type="text/javascript">
function killEnter(e){
e = e? e : window.event;
var k = e.keyCode? e.keyCode : e.which? e.which : null;
if (k == 13){
if (e.preventDefault)
e.preventDefault();
return false;
};
return true;
};
if(typeof document.addEventListener!='undefined')
document.addEventListener('keydown', killEnter, false);
else if(typeof document.attachEvent!='undefined')
document.attachEvent('onkeydown', killEnter);
else{
if(document.onkeydown!=null){
var oldOnkeydown=document.onkeydown;
document.onkeydown=function(e){
oldOnkeydown(e);
killEnter(e);
};}
else
document.onkeydown=killEnter;
}
</script>

seems to work fine too. The important 'trick' is that in functions assigned to events in FF and most modern browsers, the preventDefault object must be used if available rather than merely returning false. Some events cannot be interfered with though, however this doesn't seem to be a problem here.

[Dal]

Thanks Jesdisciple and jscheuer1

function StopReturnKey(event)
{
    //alert(event.which);
    if(IDBrowser != "IE" && event.which == 13) event.preventDefault();
	else if(IDBrowser == "IE" && window.event.keyCode == 13) return false;
    else return true;
}

//...
<form action="" name="myform" method="post" enctype="multipart/form-data" onkeypress="StopReturnKey(event);"> <!-- form tag (I upload some images hence the enctype attribute -->

I could have used your advice earlier this morning but unfortunatly I needed to get this working so after trying various methods posted on various boards across my google search I though of it logically and devised my own solution. I used onkeydown originally but thought that onkeypress might be a little more secure in capture, however Ill change this back as you stated Jesdisciple, onkeydown is still more conventional.

jscheuer1: there one hell of a size scripts for doing the job. Im sure I can use all of these methods if I need to fine tune. The main thing I wanted to avoid is slamming more event captures into each form entry so the form event capture does the whole lot. Seems to work in IE, FF, Opera and safari any other browser then you take your chances. I did however think that this type of event would be easily turned off/on via javascript, Im expecting too much from that though

Thanks again
Kind regards
Dal

PS: seems I got a lot more response from this forum than the ever dying programmingtalk forum (for javascript atleast). So thanks!

[jscheuer1]

jscheuer1: there one hell of a size scripts for doing the job.

Not really, the shorter version you posted uses browser sniffing (almost always a bad idea) the code for which, if included, would make your function about the same size as my original version. I added the part that uses eventListener and attachEvent just for compatibility purposes should the script be used on a page that already had an onkeydown assignment, but its added code is generally not required. An advantage to my version as well is that it requires no assignments in the form(s) on the page. If you were to have a few forms, the added code from that included in your version would bloat it a bit more, relatively speaking.

[Dal]

Cool, thats noted, Oh about my BrowserID function which I didnt include uses my own version of browser detection. It bases alot on the navigator.userAgent string which seems to work wonderfully accross all major browser types although the website will only utilise the latest technologies (no support for older browsers) I dont need to cover anything outside a specific scenario. Other event attachments are only geared towards the mouse (mousedown,mouseup and mouseclick) so this script will not have any consequence. I was looking for someone to answer me back the way you have jscheuer1 as I am a little in the dark with doing things my own way rather than googling ever script request so thank you. Im sure the script will serve its purpose for this perticular page but if I need to apply a tighter alternative I will certianly be back on this thread to pickup these scripts.

Kind regards and many thanks
Dal.
Is there an option to append this thread title with solved like programmingtalk forum or do I simply leave it open?

[jscheuer1]

We generally don't close topics in these forums or mark them solved in any way. I can close the thread for you, but I'm not sure it needs to be, or that it is necessarily over. Others may have views. We usually just close a thread if it is getting somehow out of hand, or especially as happens with certain types of questions, becomes an invitation to spammers.

Now, I would hope that if you are sniffing the browser that you are using more than just the userAgent string, because that can be spoofed in Safari and others to make it appear to be IE, but once such a browser passes that test, it may not be able to handle the code for IE. That is why I prefer feature (object) detection as I have used in my function. The script uses what exists. It doesn't care or need to know which browser is being used.

[Dal]

Thanks jscheuer1 wasnt sure if I needed to mark this post. So left open is fine if thats the way it works.

My browser sniffing works on useragent string alone (just checked my script) but it handles safari and opera strings. Its not that important to me as I am simply displaying a notice to users to make use of IE or FF (FF prefered) since these two are the main stream, safari, opera, flock, avant, konquerer and anyother sub-standard (less than 10% global use) is although tested, NOT garanteed. This isnt a problem as the site uses only the LATEST technologies so if the script thinks its a gecko engine and its not, then the site features probably wouldnt work anyway.

Object detection is good but I prefered to use the simple string test for the simple fact that if a nonstandard browser is used...goodluck.
I only test for
IE6 - Not supported
IE7 - supported, some bugs with W3c compliancy
IE8 - supported, some bugs with W3c compliancy but less than IE7
FF < 2 - Not supported
FF 2 - supported, some bugs with certain features
FF 3 - supported
Avant - supported (latest ver)
Opera - supported (actually quite good!)
Safari - Not supported problems with z-index /zIndex features from CSS
Flock - Well much the same as FF

Anything else is regarded as unknown and user is advised to download FF3. I kinda take the same approach on technical support, download the latest drivers and update windows/linux to the latest patches. Same applies to the website browser. Im not trying to be akward just advise users what the site was intended to use.


Thanks again.
Dal

[jscheuer1]

You are not just relying upon browser sniffing to advise users as to the best browser to use. You are also using it in your enter key function, possibly other places as well. If a Safari browser spoofing IE 7 or FF 3 encounters your site, as I understand it (I may have missed something here) they will get no warning to use another browser, but will have problems with the site.

Also, if z-index is the only problem in Safari, you are probably just doing it wrong. Though I am referring to Safari 3, which is a very good browser in many respects. Safari 2 was less so.

Another problem with browser sniffing is that the criteria that establishes a browser may change over time, there is no standard for it, so it isn't guaranteed to work. Well thought out object detection can always be relied upon to be up to date.