[WebPositive] middle click should open a new tab on mouse down

[diver]

Middle click outside tabs should always open a new tab on mouse down instead of mouse up.
See ​http://mmlr.dyndns.org/changeset/474

[stippi]

I can't lookup the changeset right now, but I have a faint memory that I implemented it this way for a good reason... :-)

[diver]

​http://webpositive.haiku-os.org/changeset/474
Also close existing tab on middle mouse down like it's done in Terminal.

[stippi]

I am against that, too, since it works against regular button behavior. The little thingy pretends to be a button, why make it work differently? It's done like it is on purpose. And it works like that also on other systems. If Terminal works differently, it should be fixed instead.

[diver]

What little thingy? Do you mean that small close button on a tab?

[diver]

I'm not talking about close button. What I mean is that middle mouse button should close current tab or create new one on middle mouse down, not middle mouse up. It somewhat improves responsiveness of an application. At least it does in Opera.

[diver]

ping stippi

[stippi]

Yes, I misunderstood. But with regards to what you actually meant, I would like to refer to my very first comment. Can't say more without reviewing the code.

[diver]

I've found a good explanation for this feature which pretty much sums up everything I wanted to say in the ticket description:

"Most operations on the tab row in other browsers now respond to mouse down events rather than up events for perceived performance reasons. It's quite literally half a click faster to switch tabs or close a tab on down.

Yes, it means you can't cancel a tab switch or tab close action once you've started. This is a case of optimizing UI for the vastly more common operation (switch or close a tab) by removing the uncommon operation (abort a switch or close tab operation by moving the mouse away and releasing). For some operations it's still appropriate to allow cancellation so the action is performanced on mouse up.

Rigid decades-old "always respond to mouse up so the user can cancel the operation" rules aren't correct for all circumstances.

To a lot of people, down feels "quicker" and "natural". I recall that Firefox used to switch tabs on mouseup and somewhere along the way (2.0 I think) they switched to mousedown as well."

[stippi]

Your reasoning makes sense that one should optimize for the common use-case. There are two problems with this:

• The uncommon use-case is not simply unoptimized, but it becomes impossible to perform. However, I can't remember the last time when I've actually performed it or needed to perform it. So this problem is void.
• The bigger issue is that your reasoning can be applied to the Haiku user interface in general. So I would prefer this to be changed everywhere, like all BControls, window buttons, everywhere, rather than in one application introducing inconsistency.

[diver]

How about changing this in BTab for a start?

[leavengood]

I think before we start changing core behaviors in Haiku, changing Web+ is a nice "testing ground."

Though we now have another ticket very closely related to this (#7786), and I think twinbee makes some good points, and he knows what he is talking about when it comes to latency in operating systems.

In general I think the sensible and safe road is to make most non-destructive operations operate on mouse-down. I'll eventually add a tab closing undo stack to Web+ so even that will become non-destructive too. Then maybe we could have an option to make other actions such as button clicks happen on mouse down.

[leavengood]

Fixed in hrev44432. There is still #7786 for the general use of mouse down in Haiku to improve latency, so I'm closing this one.