Rabobank trusts only Rabokeys
Friday, 12. September 2008, 17:17:09
The Rabobank site in the Netherlands has a peculiar problem caused by an even weirder script. The forum discussion explains what the problem is: the site's search box doesn't allow you to type the letter T!
This is caused by a keypress handling JavaScript - it's all on one line so I made a re-formatted copy. If you thought the bug was weird, wait till you try figuring out what the point of the script is..
The basic logic that causes the problem is: "any browser that supports addEventListener() will support charCode but not keyCode in the keypress event". As it happens, Opera does support addEventListener() but not charCode. The site blocks keypress events with keyCode 116 which is the correct keyCode for a "t" keypress. (If we didn't support addEventListener they would listen for keyDown events with keyCode 116 instead - which is what they basically intended to do.)
With the problem analysis out of the way: I simply don't get what this site is trying to do. They set one handler for keypress events to cancel them if it's the F5 key, and another handler for keyup events to call location.reload() if it's the F5 key!? See here:
So: "we don't mind that [F5] reloads the page and [enter] submits forms as long as we re-implement the browser's functionality in JavaScript".
Or: Rabobank trusts only Rabo-programmed keys?
I guess the browser's OWN implementation of [F5] and [enter] just wasn't buggy enough.
This is caused by a keypress handling JavaScript - it's all on one line so I made a re-formatted copy. If you thought the bug was weird, wait till you try figuring out what the point of the script is..
The basic logic that causes the problem is: "any browser that supports addEventListener() will support charCode but not keyCode in the keypress event". As it happens, Opera does support addEventListener() but not charCode. The site blocks keypress events with keyCode 116 which is the correct keyCode for a "t" keypress. (If we didn't support addEventListener they would listen for keyDown events with keyCode 116 instead - which is what they basically intended to do.)
With the problem analysis out of the way: I simply don't get what this site is trying to do. They set one handler for keypress events to cancel them if it's the F5 key, and another handler for keyup events to call location.reload() if it's the F5 key!? See here:
function F5DownEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
return cancelKey(evt,this.keyCode,this.target)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
return cancelKey(evt,this.keyCode,this.target)
}
}
function F5UpEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
window.location.reload(this.ctrlKey)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
this.target.parentNode.parentNode.submit()
}
}So: "we don't mind that [F5] reloads the page and [enter] submits forms as long as we re-implement the browser's functionality in JavaScript".
Or: Rabobank trusts only Rabo-programmed keys?
I guess the browser's OWN implementation of [F5] and [enter] just wasn't buggy enough.
