←back to thread

A BBC navigation bar component broke depending on the external monitor

(www.joshtumath.uk)
293 points ulrischa | 5 comments | 18 Nov 24 15:28 UTC | HN request time: 0.973s | source
Show context
marcellus23 ◴[18 Nov 24 16:32 UTC] No.42174016[source]▶
> All we had to do was change the isInvokedByMouse to check that screenX and screenY don't equal 0, rather than checking if they are greater than 0.

It's obviously extremely unlikely but what if the mouse is actually at 0,0 when the user clicks? I'm not very familiar with JS, is checking for != 0 really the best/only way to do this?

EDIT: actually upon going back, I realized I didn't fully process this sentence originally but it seems to address this:

> We should probably do further refactoring of the event handler function, since it's complicated by the fact that it also handles keydown events. For now, though, this fix will do just fine.

replies(3): >>42174129 #>>42174225 #>>42174311 #
1. nightpool ◴[18 Nov 24 16:42 UTC] No.42174129[source]▶
But they're already checking for event.name == 'click' in the revised code. So why would you want to filter out some legitimate click events?
replies(2): >>42174182 #>>42174203 #
2. marcellus23 ◴[18 Nov 24 16:47 UTC] No.42174182[source]▶
Maybe browsers will report `click` events that aren't actually created by a pointer device (maybe a screen reader or something?). But that still raises the question of why you would care. It seems to me like if the platform wants to report it as a `click`, your app should treat it as one and not try to get "clever" about it.
replies(1): >>42174558 #
3. kulor ◴[18 Nov 24 16:48 UTC] No.42174203[source]▶
Apply Chesterton's Fence principle and assume there are (hopefully) comments in the real code around why this has been put in place
4. pornel ◴[18 Nov 24 17:19 UTC] No.42174558[source]▶
For compatibility with the Web content, the `click` event has become a device-independent activation event. Sites can't be expected to listen for events from every kind of device, so instead all devices send `click`s.

They care, because focus for keyboard-controlled screen readers sending "click" should behave differently: an element inside the menu should receive focus, even though it's not the element that has been clicked. Otherwise if focus stayed on top-level menu bar, screen reader users would be lost, and had to navigate to menu's content themselves.

replies(1): >>42175535 #
5. marcellus23 ◴[18 Nov 24 18:46 UTC] No.42175535{3}[source]▶
Interesting. Seems like something that should be exposed more explicitly.