A BBC navigation bar component broke depending on the external monitor

Original Article ↗ Hacker News Discussion ↗

A front-end bug in the BBC’s navigation bar exposed how fragile UI logic can be when it relies on browser mouse coordinates like `screenX`/`screenY` to distinguish between mouse and keyboard activation, especially on multi-monitor setups where coordinates can be negative. Commenters debate why developers try to infer input type from such heuristics instead of using more robust event properties like `pointerType` or `pointerId`, and whether different behaviors for keyboard and pointer input are justified for accessibility. The incident also raises broader concerns about the complexity of accessible web components, inconsistent browser behavior, and the privacy implications of exposing screen-level coordinates to websites.

Heuristic Bug and Fix

  • Core issue: code tried to infer “mouse vs keyboard” from screenX > 0 || screenY > 0. Negative coordinates on some multi‑monitor setups made pointer clicks look like keyboard activations and broke the menu.
  • The “fix” to screenX !== 0 || screenY !== 0 is widely seen as trading one fragile heuristic for another, since a real click at (0,0) would again be misclassified.

Why Distinguish Mouse vs Keyboard Activation

  • Nav button intentionally behaves slightly differently:
    • Pointer: animate menu open, focus container.
    • Keyboard/screen reader: no animation, focus first menu item.
  • Goal is accessibility parity: sighted users see the animation; keyboard/screen‑reader users get immediate, predictable focus.

Better Ways to Detect Input Source

  • Many commenters argue you should not rely on coordinates at all. Suggested alternatives:
    • pointerType / pointerId === -1 on PointerEvent click.
    • event.detail (0 for keyboard, 1+ for pointer in practice), though some call this another hack.
    • Separate keydown and pointer handlers, or global flags tracking recent mousedown vs keydown.
  • General advice: don’t overload unrelated fields; avoid “unrepresentable states” created by parallel booleans like isInvokedByMouse and isInvokedByKeyboard.

Critique of Using Screen Coordinates

  • Multiple comments say absolute screen coordinates are the wrong space anyway; clientX/pageX or element‑relative positions better fit UI needs.
  • Using (0,0) as a proxy for “keyboard” conflicts with legitimate corner clicks and automated tests. Several people call this clearly bad practice.

Security/Privacy and API Design Concerns

  • Some question why the web exposes window position and screen‑space mouse coordinates at all, given fingerprinting and tracking risk.
  • Others note historical uses: multi‑window interactions, games, analytics heatmaps, legacy HTML4 “window choreography.”

Accessibility and Web Complexity

  • Accessibility is described as genuinely hard and often hacky because browsers, OSes, and screen readers interact inconsistently.
  • There’s tension between “don’t be clever, use defaults” and the reality that some disabled users need non‑standard behaviors or custom focus management.
  • Broader critique appears of heavy custom JS for simple UI like menus and search boxes, versus simpler, more robust HTML/CSS approaches.