IE8: Why MS loves 'MouseDown' event so much?...

Again, again and again... Why IE closes tab on "middle mouse" MouseDown event instead of MouseUp/MouseClick?
 
It's beyond my understanding...

It's always a very bad idea to do any 'complete' action inside Mouse/Key "Down" event. You can start some action like Drag-N-Drop inside such event, but not FINISH!

Good catch.  Interestingly, Opera makes the same mistake.  Safari does too, though it doesn't support middle-click closing; middle button mousedown changes tabs.  Firefox and Chrome get it right by your standards.

Maybe it's somekind of javascript standarisation, thing,..?

maybe,...

Maddus Mattus said:

Maybe it's somekind of javascript standarisation, thing,..?

maybe,...

Can't be. The "Click" event is functionally identical to the OnRelease event in Flash whereby the click is registered only when the button is released whilst in the hit area of the widget.

I've always found IE's tab bar a bit sloppy. The tabs are hardcoded bitmap resources, there's no Down state (only Up and Over), and they're not as responsive as Firefox or Opera's on the same hardware.

Maddus Mattus said:

Maybe it's somekind of javascript standarisation, thing,..?

maybe,...

Why would IE's UI be subject to JavaScript standardisation limitations?

I actually like IE's tab system more than Firefox's. In Firefox it requires a double click (instead of Single) to open a new tab, you need an addon to open them to your homepage, and I seem to have a habit of accidentally dragging sites off of the tab bar forcing them to open into a new window.

But it isn't a huge issue since I can get such an addon, and I just try my best not to pull tabs off of the tab bar.

littleguru said:

I filed this as bug... let's see what we get back.

Let me guess results... Er... Hmmm... Er... Hmmm... Nothing?
This "bug" exists in IE7 too. So, it's a feature, not a bug.

Good point. You also can't 'undo' your action by taking the cursor off the tab with the button still held down (just in case you change your mind at the last possible moment), which (I think) is one of the Windows UX guidelines.

Most operations on the tab row respond to 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 UX 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.

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

And this isn't really rocket science, not even computer science.  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.

FWIW, I'm using FF 3.0.5 and it switches tabs on mousedown. As do the tabs in dialog boxes like Outlook and Word's options dialogs. So it's not exactly foreign and weird behaviour. In fact I bet if you asked most people they couldn't tell you it behaved one way or the other without actually trying it again.

joechung said:

Good catch.  Interestingly, Opera makes the same mistake.  Safari does too, though it doesn't support middle-click closing; middle button mousedown changes tabs.  Firefox and Chrome get it right by your standards.

The latest Chrome switches on MouseDown here. Firefox too. This behavior seems consistent between all major browsers. Probably for the reasons Bruce mentioned.

BruceMorgan said:

Most operations on the tab row respond to 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 UX 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.

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

And this isn't really rocket science, not even computer science.  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.

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

This was in the Vista UX guidelines. I can understand that they're guidelines rather than rules, and that sometimes it's more appropriate to deviate from them, but they certainly weren't "rigid, decades-old" guidelines when IE7 was released.

BruceMorgan said:

Most operations on the tab row respond to 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 UX 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.

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

And this isn't really rocket science, not even computer science.  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.

As the others mentioned, tab controls have always switched on mouse down. This is the standard behavior. Left clicking on a close button in a tab closes on mouse up (in IE7 and IE8 beta), as does any standard button. Even middle clicking a link to open it in a new tab does it on mouse up. The middle click that BlackTiger is describing is the non-standard behavior.

blowdart said:

It's interesting that it's about perception, when there are still real performance problems with IE. Sucky javascript speed, slow startup when compared to firefox, rendering, etc.

That's unfair. Perceived performance is an integral part of an application's performance, not a hack you add on top once you've finished all the low-level code changes. I'm not saying there aren't any performance problems - there certainly are - but making a change to affect perceived performance is welcome regardless of any other work done.

blowdart said:

Yggdrasil said:

*snip*

Well perhaps. I guess it's an easy fix, as opposed to the underlying engine. I'm just really disappointed with IE8. I finally got around to installing it last night, it feels slower (oh look perceived performance) in startup, rendering and use. Not to mention the wasted space of the favourite bar.

15 seconds from clicking the IE icon to seeing an IE window. That is really poor.

My point is that it's not an "easy fix" - it's a serious part of the overall solution. Having the fastest engine won't help you if your perceived perception is determined by a user's click speed. Both parts ofthe equation must be addressed, not just the rendering/tab-switching speed. Insta-click is useless without a fast rendering engine, and a fast rendering engine is useless without a smart UI.

blowdart said:

Yggdrasil said:

*snip*

Well perhaps. I guess it's an easy fix, as opposed to the underlying engine. I'm just really disappointed with IE8. I finally got around to installing it last night, it feels slower (oh look perceived performance) in startup, rendering and use. Not to mention the wasted space of the favourite bar.

15 seconds from clicking the IE icon to seeing an IE window. That is really poor.

And incidentally, I never see 15 second wait times with IE. With a relatively clean IE install (nothing but Java and Flash, I think) I get 3-4 seconds, as opposed to Chrome's ~1 sec and FF's 7-8 seconds (again, with very few addins if at all).