A BBC navigation bar component broke depending on the external monitor

> 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.

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?

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.

Apply Chesterton's Fence principle and assume there are (hopefully) comments in the real code around why this has been put in place

It seems that querying the screen position is just a heuristic they came up with to determine the nature of the event. Instinctively I would use instance of MouseEvent for this, but even this feels risky/hacky to me.

My question is why they're relying on those heuristics. My guess is that toggleMenu is being used by multiple event handlers. Or maybe there's something else going on that is specific to their codebase.

It's hard to judge without knowing the full picture.

EDIT: Aha, there's an answer here: https://news.ycombinator.com/item?id=42174177

No its not. You can do media select on if the primary input device is a pointer device (and, further, if it has high accuracy) and then filter on that.

I used it to select which layout to show in the past.

If you want to listen to input on touch only then you can do that and call preventDefault on the event so that the browser does not then cause a click event. Or you can just save yourself the trouble and write a click handler.

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.

Interesting. Seems like something that should be exposed more explicitly.

You can do a search on GitHub and there is quite a bit of code that is using event.screenX > 0. Maybe someone should file some bug reports.

Also, stack overflow suggests that exact code to "differentiate between mouse and keyboard triggering onclick": https://stackoverflow.com/questions/7465006/differentiate-be...