var x = 215;
function setup() {
createCanvas(480, 120);
}
function draw() {
if (keyIsPressed) {
if (keyCode == LEFT_ARROW) {
x--;
} else if (keyCode == RIGHT_ARROW) {
x++;
}
}
rect(x, 45, 50, 50);
}
In Chromium, the rectangle is moving, when the left or right arrow keys are pressed. In Firefox, the rectangle does not move, when pressing the arrow keys.
To check, what's in keyCode, I added console.log(keyCode); right below the first if-statement. As expected, in Chromium, the key codes 37 and 39 are logged. But in Firefox it's always key code 0.
In Firefox, I found a way to actually make the rectangle move, by pressing really quickly right-left-right-left arrows (dunno why), and when it moves the keyCode are indeed 37 or 39
Edit : However, it moves toward the side opposite the arrow...
Edit 2 : Added image and code
// x 卤= 5 is just to make rectangle moves more obvious
// and I switched + and - to make the rect go in the actual arrow direction
var x = 215;
function setup() {
createCanvas(480, 120);
}
function draw() {
background(100);
if (keyIsPressed) {
console.log(keyCode);
if (keyCode == LEFT_ARROW) {
x+= 5;
} else if (keyCode == RIGHT_ARROW) {
x-= 5;
}
}
rect(x, 45, 50, 50);
}

Ok, the main reason of this unusual behavior is _browser compatibility_.
In p5, the keyboard event has three main activities attached: onkeydown, onkeyup and onkeypress.
Chrome and Firefox handles onkeypress in __little__ different ways. For chrome onkeypress event doesn't fire up with arrow keys and for firefox it doesn't fire up on modifier keys (Alt, CTRL, Shift etc.).
So when Arrow key is pressed, the events fired up in chrome are:
and in firefox the events are:
The behavior in firefox is due to extra onkeypress occurrence. p5 prevents user from multiple firings of key. See this file.
__My initial thoughts:__ For this kind of functionality keyIsDown() is the better approach as in it only one single event is associated with the element.
var x = 215;
function setup() {
createCanvas(480, 120);
background(120);
}
function draw() {
if (isKeyPressed) {
if ( keyIsDown(LEFT_ARROW)) {
x--;
} else if (keyIsDown(RIGHT_ARROW)) {
x++;
}
}
rect(x, 45, 50, 50);
}
@lmccart What do you think in this? Should we improve the code of keyboard event (also it is using KeyboardEvent.which() which is deprecated now)? Or am I missing something?
@vipulrawat thanks for looking into this. I think it would be great to do a review and update of keyboard event handling as I don't think it's been touched in a little while, and as you mention, some things are out of date and not working. would you be interested in taking this on?
i just tested this on Firefox 63.0.3 and it works just fine. i'm not sure i understand the explanation above.
https://codepen.io/Spongman/pen/NELOLz?editors=0010
EDIT: i tried both on win10 and ubuntu.
i just tested this on Firefox 63.0.3 and it works just fine. i'm not sure i understand the explanation above.
https://codepen.io/Spongman/pen/NELOLz?editors=0010
EDIT: i tried both on win10 and ubuntu.
Indeed, using keyCode == works well on Codepen website but not on p5 web editor
I tried this in firefox and it doesn't work for me too.
@lmccart I would love to take up on this issue.
I'm reading the P5.js book at the moment and for learning purposes, I'm implementing the examples in their own HTML files. This is the full code used for the example I mentionend in the opening post:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Move with Arrow Keys</title>
<link rel="stylesheet" href="css/style.css" />
</head>
<body>
<script src="js/p5.min.js"></script>
<script type="text/javascript">
let x = 215;
function setup() {
createCanvas(480, 120);
}
function draw() {
if (keyIsPressed) {
console.log(keyCode);
if (keyCode == LEFT_ARROW) {
x-=10;
} else if (keyCode == RIGHT_ARROW) {
x+=10;
}
}
rect(x, 45, 50, 50);
}
</script>
</body>
</html>
Note: The included stylesheet is irrelevant here, it only sets the background colour of the body.
Has anyone reproduced this outside of the web editor?
I doubt it鈥檚 a p5 library issue.
Has anyone reproduced this outside of the web editor?
I doubt it鈥檚 a p5 library issue.
I got it outside the web editor.
var x = 215;
function setup() {
createCanvas(480, 120);
}
function draw() {
if (keyIsPressed) {
if (keyCode == LEFT_ARROW) {
x--;
} else if (keyCode == RIGHT_ARROW) {
x++;
}
}
rect(x, 45, 50, 50);
}
@Spongman @lmccart I would like to work on this issue.
Ok. Here is a small insight into the issue. I have tested the code in these environments:
__Issue:__ The unexpected behavior of some code that involves keyboard event in chrome and firefox. The box is not able to move(smoothly) in firefox when using arrow (left, right) keys but works perfectly in chrome.
__p5.js__ v0.7.2
__Browsers:__ Chrome (v70.0.35), Firefox (v60.0.1)
__OS:__ Linux kernel 4.15.0-29 64-bit, macOS mojave
__Editor:__ Codepen, p5 web editor
__Links:__ Problem Codepen | p5 web editor
Table of working breakdown:
| using keyCode | Firefox | Chrome |
|---|---|---|
| Codepen | __NO__ | YES |
| Editor | __NO__ | YES |
According to me, use of keyIsDown() is more appropriate while trying handle movement of the element using arrow keys (one can try to change the code in above links with keyIsDown(LEFT_ARROW/RIGHT_ARROW)).
| using keyIsDown() | Firefox | Chrome |
|---|---|---|
| Codepen | YES | YES |
| Editor | YES | YES |
@lmccart I would love to do this once the unusual behavior in the different browser gets confirmed by other users too.
@Spongman I may be wrong but if you overwrite _onkeypress in p5 library to do nothing (that is not registering the keypress event) i.e. just return; the code using keyCode works fine in both the browsers. The thing about not registering onkeypress by chrome here
@ThatIsAPseudo Are you still getting correct results using keyCode in codepen but not in p5 web editor?
@vedhant Do you want to this issue on or shall I do this.
@vipulrawat can you try this with the latest version of firefox?
scratch that. i see it now in firefox 64 on windows.
i further investigated the issue and have concluded as following :
As mentioned above by @vipulrawat :
When Arrow key is pressed, the events fired up in chrome are:
and in firefox the events are:
The documentation for onkeypress event as described in MDN web docs :
The keypress event is fired when a key that produces a character value is pressed down. Examples of keys that produce a character value are alphabetic, numeric, and punctuation keys. Examples of keys that don't produce a character value are modifier keys such as Alt, Shift, Ctrl, or Meta.
Clearly, when Arrow key is pressed the onkeypress event should not fire up. In chrome onkeypress is not triggered when the key is not a character value. However, in firefox the keypress event fires up irrelevant of the key actually pressed. The catch here is even though firefox fires onkeypress event for every key, the 'e.which' value is set to 0 if it is not a character value. If it is a character value then it is set to its ASCII value as expected but for keys like LEFT_ARROW, RIGHT_ARROW etc, it sets e.which to 0.
Therefore, when Arrow key is pressed in firefox, the keyCode value is been set to 0.
Possible Fix :
p5.prototype._onkeypress = function(e) {
if(e.which === 0){
return;
}
if (e.which === this._lastKeyCodeTyped) {
// prevent multiple firings
return;
}
this._setProperty('keyCode', e.which);
this._setProperty('_lastKeyCodeTyped', e.which); // track last keyCode
this._setProperty('key', String.fromCharCode(e.which));
var keyTyped = this.keyTyped || window.keyTyped;
if (typeof keyTyped === 'function') {
var executeDefault = keyTyped(e);
if (executeDefault === false) {
e.preventDefault();
}
}
};
@vipulrawat @lmccart @Spongman if you guys permit me, I would like to fix this issue.
@vedhant Instead of using e.which, I think it's better to use e.key and update the keyboard events in p5. Reason being:
e.which is deprecated and may lose its effect in coming years with recent web engines.e.key doesn't results out into Unicode. Also it has better fallback techniques like "dead key" or "unidentified key"@vipulrawat Yes you are right. We should use e.key instead of e.which for all of the keyboard events.
I also checked e.key value for onkeypress in firefox and it gives correct results for non character values.
Can you allow me to do the changes?
@vipulrawat e.key doesn't give out Unicode. What can we use to set the keyCode property in p5 for which previously e.which was used?
@vedhant Sorry, for the late reply. I think e.key would be sufficient one can modify the code little to validate the output of e.key rather than any Unicode. Or you can try other possible solutions also.
// Click any key to display it!
// (Not Guaranteed to be Case Sensitive)
function setup() {
fill(245, 123, 158);
textSize(50);
}
function draw() {
background(200);
text(key, 33, 65); // Display last key pressed.
}
In the second comment, why is it mentioned that it is not guaranteed to be case sensitive?
Also, I am removing keyCode property from p5 and instead using key property everywhere. Is it fine @vipulrawat .
@vedhant Using key will be good until unless it is not breaking anything else in p5. One thing that I recommend is that other people in the p5js community will also review when the PR is made.
Tested this on Firefox v65.0a1 Nightly with p5js v0.7.2, there onkeypress event doesn't fire up when arrow key is press, which is what supposed to happen, so the behaviour is as expected. So this issue of firefox will be fixed in upcoming stable releases of firefox.
So, it's not library issue but browser issue.
@savvysiddharth Do you have a link to a bug report on Mozilla's Bugzilla for this?
here's the bug report on bugzilla,
https://bugzilla.mozilla.org/show_bug.cgi?id=968056
which got fixed by this bug which is tracked as firefox65+,
https://bugzilla.mozilla.org/show_bug.cgi?id=1496288
@ikselven
Thanks :)
Edit: Tested the example code from https://github.com/processing/p5.js/issues/3346#issuecomment-442457487 with P5.js v0.7.2 in Firefox Developer Edition (v65.0b1) and it works for me now. Looking at the Firefox release cycle, Firefox 65 will be released on January 29, 2019.
Firefox 65 has been released today. I cannot reproduce the issue anymore and the example works fine now.