A BBC navigation bar component broke depending on the external monitor

For anyone who didn't click through to the WebKit bug report the author submitted, a WebKit dev asked him to clarify why the BBC finds it beneficial to be able to detect that the event was sent from a keyboard. This is the author's response:

> Ironically, I want interoperability on this to help with use cases relating to accessibility.

> I work at the BBC and, on our UK website, our navigation bar menu button behaves slightly differently depending on if it is opened with a pointer or keyboard. The click event will always open the menu, but:

> - when opening with a pointer, the focus moves to the menu container.

> - when opening with a keyboard, there is no animation to open the menu and the focus moves to the first link in the menu.

> Often when opening a menu, we don't want a slightly different behaviour around focus and animations depending on if the user 'clicks' with a pointer or keyboard.

> The 'click' event is great when creating user experiences for keyboard users because it is device independent. On keyboards, it is only invoked by Space or Enter key presses. If we were to use the keydown event, we would have to check whether only the the Space or Enter keys were pressed.

Source: https://bugs.webkit.org/show_bug.cgi?id=281430

This is fascinating, because the naive English interpretation of the code and the comment on that WebKit bug don't match the actual structure of the code. Here's the relevant code:

    const isInvokedByMouse = event => event.screenX > 0 || event.screenY > 0;
    const isInvokedByKeyboard = event => isEnterKey(event) || isSpaceKey(event);

Ignoring the actual conditions entirely, this code seems to be trying to categorize the event into one of two categories: mouse or keyboard. But what it actually does is to categorize into one of four categories: (mouse and not keyboard), (keyboard and not mouse), (keyboard and mouse), and (neither keyboard nor mouse). And, as the original bug shows, (neither keyboard nor mouse) is handled inappropriately. One might wonder whether (keyboard and mouse) works well.

Either the code should be deliberate about the fact that (is it a keyboard) and (is it a mouse) are separate booleans, or the code should be structured so that the actual categories are mutually exclusive. For example:

    const isInvokedByMouse = ...

and use !isInvokedByMouse to check for keyboardiness, or:

    const eventSource = ... (returns "keyboard" or "mouse")

or, perhaps even better:

    const eventSource = ... (returns "keyboard", "mouse", or "not sure")

This is a great comment ^ whenever you use two booleans like this, you're opening yourself up to "unrepresentable state" logic errors. Finding and noticing this in code can be tricky, but it's a great example of something that should be caught during code review.

Not sure if exactly the same thing but reminds me of "Booleans are a trap"

https://katafrakt.me/2024/11/09/booleans-are-a-trap/

Yet another article prematurely optimizing. It’s like these people have nothing better to do. I’ll wait for my code to get into stupid edge cases first and then fix it. Even if you spend your time avoiding booleans you will still find yourself with some new contradictory state and have to fix it differently anyways.

The issue isn’t booleans the issue is that the code doesn’t handle all the states described by the two booleans, when all are possible.

Make the impossible states unrepresentable using an enum of only the possible boolean combinations.

Did you read the context?