3 ms·
...because when they are 0 one can infer that the event came from a keypress rather than a mouse. They want to know this.
by t43562 2y ago
...because when they are 0 one can infer that the event came from a keypress rather than a mouse. They want to know this.
- shdon 2y agoThen it would make a lot more sense to check event.pointerType == 'mouse' vs event.pointerType == '' (for keyboard)
- deleted 2y ago[deleted]
- jorams 2y agoThat 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.
- G1N 2y agoBased 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.
- hyperhopper 2y agoThis does not work when the mouse is actually at 0,0
- xboxnolifes 2y agoAn imperfect solution for a situation that will practically never happen and have no noticeable downside.
- noworriesnate 2y agoIt'll screw up UI tests
- xboxnolifes 2y agoClearly not, otherwise this bug would have been found much sooner.