This question already has answers here:
ReferenceError: event is not defined error in Firefox
(2 answers)
Closed 6 years ago.
I'm using this code to check for keydown and display the string 'Pressed' while a key is down.
<body onKeyDown="doKey(window.event.keyCode)" onKeyUp="doKey2(window.event.keyCode)">
<script>
function doKey($key) {
document.getElementById('keydown').innerHTML='Pressed';
}
function doKey2($key) {
document.getElementById('keydown').innerHTML='';
}
</script>
<div id="keydown"></div>
The problem is that for some reason it's only working on Chrome. I think the 'window.event.keyCode' doesn't return anything. How do I make it work at least in Firefox too? Thanks
Some browsers have a global event object, other send the event object to the event handler as a parameter. Chrome and Internet Exlporer uses the former, Firefox uses the latter.
Some browsers use keyCode, others use charCode.
Use arguments[0] to pick up the event object sent as a parameter, and if there is no object there, there is a global object instead:
onkeydown="doKey(arguments[0] || window.event)"
In the method you can check for either keyCode or charCode
function doKey(event) {
var key = event.keyCode || event.charCode;
...
}
Note the lowercase name onkeydown. If you are using XHTML event names has to be lowercase, or the browser might ignore it.
<html>
<body onKeyDown="doKey(event)" onKeyUp="doKey2(event)">
<script>
function doKey(e) {
evt = e || window.event; // compliant with ie6
document.getElementById('keydown').innerHTML = evt.keyCode+' Pressed';
}
function doKey2(e) {
document.getElementById('keydown').innerHTML='';
}
</script>
<div id="keydown"></div>
</body>
</html>
If we passed event as parameter, most modern browsers will work well. I have tested with Chrome 12, Firefox 4, IE 7/8/9.
I've run into the same problem, as I'm sure thousands of coders have.
The problem is that the browsers (other than IE) don't like window.event.
I'm poking around trying to find a solution (which is how I stumbled across this), and I found the following (so far):
1) Write JQuery:
$(document).keyup(function(e) {
var GetKey = e.keyCode;
`enter code here`
}
});
2) Redefine the key variable:
var key = (window.event) ? evt.keyCode : evt.which;
I tried the JQuery solution. It seems to be okay in FF, but I ran into an unexpected bug in IE that I'm still trying to solve. I haven't yet tried the second solution; that's next, if I can't get the JQuery to work.
Related
This question already has answers here:
'innerText' works in IE, but not in Firefox
(15 answers)
Closed 7 years ago.
I'd getting some errors on my scripts here, in the first one I've declared a var text(); type to create a box with some text content.
var x=$('#x').text();
In my second .js I'm doing some handling on this var that ensure my text i'll have less char than max-length, here is:
var limitMaxLength = function(element) {
var maxLength = $(element).data("max-length");
if (maxLength) {
$(element).on("keypress", function(event){
if (event.target.innerText.length > maxLength || event.keyCode === 13) {
event.preventDefault();
}
});
}
};
So I having some issues on Firefox getting this error:
[TypeError: event.target.innerText is undefined]
In IE, Opera, Chrome and Safari my code works fine, i'm getting error only on Firefox.
*Sorry for my bad english.
innerText was a Microsoft Creation, left over from the days of old. Firefox decided not to support it in favour of the w3 compliant, textContent. However, IE8 & below do not support textContent, therefore, if you wish to support Legacy browsers, you're in a bit of a bind.
var text = elem.textContent || elem.innerText;
or
elem.innerHTML // eww, but it works, eh?
or, just ditch IE8 (easier said than done, especially at work)
innerText is not supported in FF.
You can fix the issue by using dynamic property names. At first, check which property is supported:
var textContent = ('textContent' in document) ? 'textContent' : 'innerText';
Define textContent as a global variable (or within the outmost scope), then you can use it like this:
var someText = elem[textContent];
This snippet gives you textContent if it's available, innerText otherwise. Notice also, that there's a small difference between these two properties.
A live demo at jsFiddle.
Though when you're using jQuery, why not just:
$(event.target).text()
$(document).keydown(function (event)
{
alert(event.which);
});
For the semicolon key, ;, this gives 59 in Firefox and 186 in Chrome. However, from the jQuery reference page for the keydown event, it says
"While browsers use differing properties to store this information, jQuery normalizes the .which property so you can reliably use it to retrieve the key code. This code corresponds to a key on the keyboard, including codes for special keys such as arrows."
Am I missing something?
The which property is a "one stop shop" for which key was pressed, allowing you to ignore the differences between the keyCode and charCode properties. That is the "normalization" that jQuery provides.
The difference in the value of which comes down to a difference between the way the various browsers supply the information - so you'll have to write code to handle the different values that come back. There are a few references to this behavior online.
A quick Google search says you will simply have to test for both. This is a consistent inconsistency with Firefox.
I don't know about jQuery but I'd suggest sticking to keypress events for typing keys and only using keydown events for special keys such as arrows.
Here is the entirety of the "normalization" that jQuery does:
if ( event.which == null ) {
event.which = original.charCode != null ? original.charCode : original.keyCode;
}
Looks like it just gets keyCode if charCode doesn't exist. And charCode is only used if event.which doesn't already exist. It doesn't change the numbers around to make them consistent.
I'm working on a web app that works fine inside the LAN using HTTP but when I test it remotely over SSL it fails for IE (7 & 8). Firefox, Camino and Safari all work perfectly.
I've tracked down the issue to key being undefined. The relevant bit of code is:
function showResult(e,str,num) {
var key = (window.Event) ? e.which : e.keyCode;
if(((key > 32 && key < 58) || (key > 64 && key < 91) || (key > 95 && key < 123)) && (str.length >= num)) {
Any clues as to why key would be undefined for IE over SSL but works fine over HTTP? Better yet, can someone tell me how to overcome this problem? FWIW, I don't need to support IE prior to version 7.
Update:
There was an answer which suggested replacing
var key = (window.event) ? e.which : e.keyCode;
with
var key;
e = e || window.event;
key = e.keyCode || e.which;
That works. The problem now is that I can't accept that answer because it has been deleted.
Ok, I'll re-add that answer, even though it wasn't mine, and add some info along the way so you can feel OK with accepting it even if it wasn't my answer from the beginning.
So, the suggested code is this:
var key;
e = e || window.event;
key = e.keyCode || e.which;
What does || do? For one it's the logical or operator, which would return true if one of the sides evaluate to boolean true.
It also has another use in JS. If you give it two arguments and the first one is undefined, it will return the second argument. This means, in the code above, that if e is undefined, you instead get window.event which is IE's traditional event object.
Same thing goes with e.keyCode || e.which whichever one exists is used. So in the end, you're likely to end up with a valid key code on various browsers. All is good in wonderland.
But wait, doesn't your original code do something similar?
var key = (window.Event) ? e.which : e.keyCode;
Uh-huh. What's that? JavaScript is case-sensisitive, so window.Event is not the same as window.event in the code above. window.event is IE's traditional event object that you would use get information about the event that occurred, while window.Event (which you can see from the initial capital letter) is a constructor, or more specifically in this case an interface.
Point is, in that code it was used to detect Mozilla. If it exists, choose e.which (One of the places where Mozilla stores the key code) otherwise go for e.keyCode where IE would store the key code.
However, this is based on the flawed assumption that IE doesn't have the window.Event constructor defined. It does have it defined as of IE8, at least. This means that e.which is chosen over e.keyCode, on newer versions of IE. e.which has never and will never be supported in IE. That's why key ends up being undefined.
But, uhm, why does it differ between encrypted and unencrypted connections? That's a good question. While I cannot know for sure without access to your development environment, I would assume it has something with IE's compatibility modes.
IE has historically (over the last 10 years) been the most quirky and non-standard browser around. This has lead to people a) programming ignorantly according to IE's standards b) creating workarounds for IE's behaviors. If MS just made IE standards-compliant, that would break many pages which rely on IE's quirky behavior in one way or the other. Microsoft has ackowledged this by making IE8+ emulate older versions of IE so pages won't break, unless told otherwise.
I can only assume that, for whatever reason, in your test environment the page ends up running in the "IE7" mode which might not have the window.Event constructor/interface defined. This would make your old code use e.keyCode which is ey OK. Then perhaps in your production environment, or maybe just because of the encrypted connection (only ghawd knows what MS is doing) you end up with a newer IE mode so window.Event is actually defined and e.which is chosen. This makes IE a cheeky monkey.
Bottom line: Use the new code.
Most probably, you've included a script over http (rather than https), which will fail to load because the page itself is secure and the included file insecure.
I'm new to dealing with BlackBerry devices. I'm currently running into a JavaScript issue on a 9700 and trapping keypress events and getting a proper keycode.
I have this javascript:
function numbersonly(e) {
var key
if(window.event) {
key = window.event.keyCode; // IE
}else{
key = e.which; // Firefox
}
alert('keycode : ' + key);
}
And it's attached to an input field via an unobtrusive addEvent script.
On a standard desktop browser (Firefox and IE), it does what you'd think it does...pressing a key will show the keycode via the alert.
On a blackberry, however, pressing a key does one of two things:
if the key presses is the numbers 1 through 9, nothing happens.
if it's any other key, the keyCode is 'undefined'.
Any idea what's going on? I assume it's a limitation of the BlackBerry JavaScript support.
UPDATE:
Tested this on a 9800 Simulator as well, which is running OS6. Problem doesn't exist there. So this is either an issue with BlackBerry OS5 or BlackBerry's physical keyboard.
I'm not sure if the event variable is set when you add an inline event handler.
Have you tried setting the event-handler from javascript. So something like
document.getElementById('mytextelement').onkeypress = keytest;
Try using e.keyCode instead of e.which
I am looking at some JS code from the 20th century, and they are using document.layers in code that is trying to get the current key code. What browser are they sniffing for?
i am about to replace the code with something like this:
var fn = function(event){
event = event || window.event;
var code = event.charCode || event.keyCode;
}
but i am afraid of breaking something arcane and releasing the evil
document.layers exists in Netscape 4 and holds all <layer> and <ilayer> elements.
It was an early precursor to true DHTML.
For more information, see here. (Ten years old)
Netscape 4 is not able to display any modern web-page due to it's total lack of CSS support - so if you drop the support for this browser then you are not breaking anything that isnt already broken.