Switching Chrome tabs works on button-down. Activating the three-dot menu in Chrome also works on button-down (which is good) but then it needlessly fades from 0% to 100% opacity (which is a crime against nature).
I didn't even have to go digging in the memory hole to find this. It's right here in front of me.
> Switching Chrome tabs works on button-down.
True; the same in Firefox. That is interesting. Perhaps it’s because simply selecting a tab is considered a safe and reversible operation. I did use the word “decisive” for a reason.
Or at least it did in classic Win32 UI. You can still see this in action if you open, say, Disk Management. But in Win11 Notepad (which is modern XAML), holding mouse down will open the drop-down submenus, but you won't actually be able to activate an item by releasing the mouse button while hovering over it, so it seems that someone partially copied the design without understanding its purpose.
Mouse interactions have (at least) 5 different events: hover, down, up, click and double click. The interactions you describe all happen “onclick”, which requires a down and up event to happen consecutively.
I get your point, that small delays add up, but mouse events aren’t a great example, IMO. Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown.
> Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown.
That's stated as if it is a rule, but why is that a rule?
And if if is a rule, then why does Chrome -- for example -- handle this inconsistently?
Clicking on a different Chrome tab sure seems to happen with ondown, but clicking on the "reply" button below the text box I'm typing into works with onclick.
X window was the odd one out in the old days that would show a context menu on mouse down. Made it feel a bit unrefined.
Maybe it's so if you're going to start dragging the window/tab you can see what is in it.
The inconsistency is bizarre, since some here say that clicking-and-releasing before a resultant thing is allowed to happen is a hard-and-fast rule of GUI implementation that has been in place for decades, but that just doesn't seem to be the case at all.
Buttons normally only respond to the “on click” event. This lets you move off the button if you change your mind mid-click.
Window focus is normally an “on down” event because you might want to see what’s behind it while doing something else before you release the button (like drag it around). But focus used to be “on hover”, where just moving your mouse over a window brought it to the foreground. “On up” wouldn’t make sense because if you wanted to do something like move the window around, you couldn’t as you’ve now released the mouse.
It all depends on what you’re trying to do and the OS. Each OS has a design language that “tries” to bring some consistency to event handling. But ultimately, it’s up to the application to handle many things.
I just tried this on Firefox and can confirm similar behaviour. Some of the things I clicked on appear to have some alternate long-press function despite having a pointer device with multiple interaction modes.
It seems we have condemned our desktops to large latencies on the off-chance someone might try and interact with them using touch.
UI buttons have activated on the mouse-up event since forever ago. There's a reason: to give the user the choice of backing out of an action even after the user has pressed the corresponding button. They can just move the pointer off the button, release, and the action will not be committed.
John Carmack made this same point recently. John Carmack is wrong. Maybe the trigger on your gun in Doom needs to respond on mouse down, for the immediacy and realism -- that's how real gun triggers work, no takesie-backsies once it's pulled. But especially for potentially destructive UI actions such as deleting or even saving over a file -- or launching the nuclear missiles -- you want to give the user every opportunity to back out and only commence the action once they've exhausted all those opportunities.
It's been that way since the 1984 Macintosh -- since a time people remember as having much snappier UIs than now.
Besides which, worrying about the few milliseconds lost each time a button waits for the release is pennywise and pound-foolish; there are much larger, more egregious sources of lag (round trips to the server, frickin' Electron, etc.) we should work on first.
One thing I've noticed lately is mouse lag. Like, say, in Ye Olde Start Menu on Windows: Move the mouse to the Start menu, and press the mouse button down. Nothing happens. Release the button, and then: Something happens.
The menu is triggered on button-up events, not button-down events. This adds a measurable delay to every interaction.
Same with Chrome when clicking on a link: Nothing happens until the button is released. This adds a delay.
I mean: Go ahead and try it right now. I'll wait.
And sure, it might be a small delay: After all, it can't be more than a few milliseconds per click, right[2]? But even though the delay is small, it is something that is immediately obvious when opening the "Applications" menu in XFCE 4, wherein: The menu appears seemingly-instantly when the mouse button is first pushed down.
[1]: It took me more than three tries to pick a streaming device from Plex on my phone yesterday. I'd press the "cast" button, and a dynamic list of candidate devices would show up. I'd try to select the appropriate candidate and before my thumb could move the fraction of an inch to push the button, the list had changed as more candidate devices were discovered -- so the wrong device was selected.
So I then had to dismantle the stream that I'd just started on the wrong device, and try (and fail) again.
[2]: But even small delays add up. Let's say this seemingly-unoptimized mouse operation costs an average of 3ms per click. And that 100 million people experience this delay, 100 times each, per day.
That's nearly an entire year (347 days) of lost human time for the group per day, or 347 years lost per year.
Which is 4.4 human lifetimes, per year that are lost within the group of 100 million, just because we're doing mouse events lazily.