Ancestors

Toot

Written by Josh Tumath on 2024-11-08 at 17:58

Ever had a component on your website break depending on whether the web browser was open in an external monitor? 🤯

That's exactly what happened to someone in my team. We had a very interesting time working out the root cause. Here's a blog post. https://www.joshtumath.uk/posts/2024-11-08-how-a-bbc-navigation-bar-component-broke-depending-on-which-external-monitor-it-was-on/

=> More informations about this toot | More toots from joshtumath@mastodon.social

Descendants

Written by Patrick H. Lauke on 2024-11-10 at 21:38

@joshtumath not tested, but am assuming that for relatively modern browsers you could also just test what the event.pointerType is. if it's "mouse" or "touch" or "stylus", it came from one of those devices. for keyboard it should be blank https://w3c.github.io/pointerevents/#dom-pointerevent-pointertype

(modern browsers should have "upgraded" click events to be pointer events by now)

=> More informations about this toot | More toots from patrick_h_lauke@mastodon.social

Written by Josh Tumath on 2024-11-10 at 22:13

@patrick_h_lauke oh that's a game changer!! I could always feature detect it and fall back to the rubbish screenX/Y measurement if that doesn't work. Nice, thank you.

I'm hoping to start refactoring that code tomorrow so I'll look into that.

=> More informations about this toot | More toots from joshtumath@mastodon.social

Written by Patrick H. Lauke on 2024-11-10 at 22:17

@joshtumath also, randomly, remember that in some browser/screen reader combinations (depending on how the user activates a button), there will also be (either faked, or "the center of the element") coordinates passed along https://patrickhlauke.github.io/touch/tests/event-listener-coordinates.html - if that makes a difference for what actually happens

=> More informations about this toot | More toots from patrick_h_lauke@mastodon.social

Written by Patrick H. Lauke on 2024-11-10 at 22:18

@joshtumath last time i tested this was 2020 so things have likely changed https://patrickhlauke.github.io/touch/tests/results/#faked-event-coordinates (urgh, just checking, and yes this is now wildly outdated ... testing just now with Chrome/NVDA, hitting Enter on the button does lead to faked coordinates, so that old table of results definitely needs to be updated)

=> More informations about this toot | More toots from patrick_h_lauke@mastodon.social

Written by Josh Tumath on 2024-11-10 at 22:25

@patrick_h_lauke ah. So I noticed WebKit does that and I was wondering if others do that too. So it's helpful to see from your test that JAWS does it. That's great thank you.

=> More informations about this toot | More toots from joshtumath@mastodon.social

Written by Patrick H. Lauke on 2024-11-10 at 22:38

@joshtumath as said, that table is now dubious, so take with enormous pinch of salt until i get a chance to re-test :)

=> More informations about this toot | More toots from patrick_h_lauke@mastodon.social

Written by P-Y on 2024-11-11 at 06:25

@joshtumath That was a fun read!

One question related to the fix: why is the fix still checking against the coordinates not being (0,0)? Would that be an invalid coordinate?

=> More informations about this toot | More toots from py@androiddev.social

Written by Josh Tumath on 2024-11-11 at 08:36

@py If there is no coordinate, the screenX/Y properties get initialised as 0, so that's why we can check for that to determine if the event was fired by a pointer or by a keyboard.

It's not reliable, but it's the only way. (Although there is a better way, now, which I'd like to try) https://mastodon.social/@patrick_h_lauke/113460817557336178

=> More informations about this toot | More toots from joshtumath@mastodon.social