t43562 parent
...because when they are 0 one can infer that the event came from a keypress rather than a mouse. They want to know this.
Then it would make a lot more sense to check event.pointerType == 'mouse' vs event.pointerType == '' (for keyboard)
That does seem quite obviously better. Even when insisting on checking coordinates why use the coordinate system carried by the event that you have the least control over. Why not .pageX/.pageY, which can't trigger the failure case as long as you make sure the element isn't in the far top left.
Based on the other replies here it seems like it's to differentiate taps vs mouse clicks, keyboard events in js don't have a screenX or screenY property (you can run this in your browser console on this HN post to confirm):
(() => {
const logEvent = event => console.log({
coords: [event.screenX, event.screenY],
type: event.type
});
const input = document.querySelector("textarea");
// use "keydown" instead of "keypress" to detect all keyboard input instead of just character producing input
input.addEventListener("keydown", logEvent);
input.addEventListener("click", logEvent);
})();
Type in or click on the reply text input and you'll see that the coords array is undefined for all keyboard events. I haven't tried this equivalent on a touch device however, so not sure how it's handled there.This does not work when the mouse is actually at 0,0
An imperfect solution for a situation that will practically never happen and have no noticeable downside.
It'll screw up UI tests
Clearly not, otherwise this bug would have been found much sooner.