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

BlackTiger
If you stumbled and fell down, it doesn't mean yet, that you're going in the wrong direction.

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!

joechung

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.

littleguru
<3 Seattle

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

Maddus Mattus
Do, or do not. There is no try. - Yoda

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

maybe,...

W3bbo
The Master of Baiters

In reply to Maddus Mattus

#Jan 27th @ 6:14 AM

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.

ManipUni
Proving QQ for 5 years!

In reply to Maddus Mattus

#Jan 27th @ 6:14 AM

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.

BlackTiger
If you stumbled and fell down, it doesn't mean yet, that you're going in the wrong direction.

In reply to littleguru

#Jan 27th @ 6:06 AM

Let me guess results... Er... Hmmm... Er... Hmmm... Nothing? Big Smile

This "bug" exists in IE7 too. So, it's a feature, not a bug.

Bas
It finds lightbulbs.

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.

BruceMorgan

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.

rhm

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.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to joechung

#Jan 27th @ 4:52 AM

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

Bas
It finds lightbulbs.

In reply to BruceMorgan

#Jan 27th @ 8:26 AM

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.

DCMonkey
Monkey see, monkey do, monkey will destroy you!

In reply to BruceMorgan

#Jan 27th @ 8:26 AM

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
Peek-a-boo

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.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to blowdart

#Jan 27th @ 10:58 AM

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
Peek-a-boo

In reply to Yggdrasil

#Jan 27th @ 11:05 AM

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.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to blowdart

#Jan 27th @ 11:14 AM

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.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to blowdart

#Jan 27th @ 11:14 AM

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).

BHpaddock

In reply to blowdart

#Jan 27th @ 11:14 AM

What kind of system are you seeing a 15 second start-up time on?

How fast does it start in No Add-ons mode?

blowdart
Peek-a-boo

In reply to BHpaddock

#Jan 27th @ 3:20 PM

Vista 32 bit, Dell M1530 with 4Gb.

I don't think it's an add-on issue, if I look at add-ons their start times are all sub 1 second, and there's only 5 of them, none of which are esoteric aside from a FirePass activeX control used to RDP into some MS servers Smiley

I uninstall IE8 and IE7 is back to as expected, about 5 seconds to bring up a usable browser window if there is no window already open

BHpaddock

In reply to blowdart

#Jan 27th @ 10:27 PM

Even 5 seconds seems like an eternity to me. I've run IE 7 and IE 8 on a variety of systems and never had to wait that long (unless my machine was bogged down doing a build or something). There must be something wrong on your system that could be fixed. Do other apps exhibit start-up delays?

blowdart
Peek-a-boo

In reply to BHpaddock

#Jan 27th @ 11:10 PM

Nope.

Only plugin installed that you wouldn't have on a corp machine is the WHS banner.

If you can think of a good way to trace it, drop me a mail or something, I'm more than willing to try to track it down!

BlackTiger
If you stumbled and fell down, it doesn't mean yet, that you're going in the wrong direction.

In reply to BHpaddock

#Jan 27th @ 3:20 PM

IE8 RC1 starts quite quickly on my machine (<3 sec), but still "connecting" to something... somewhere... even if starts in "blank page" mode.
Not 3, just two letters... "M" and "S"...

BruceMorgan

In reply to BlackTiger

#Jan 28th @ 5:17 AM

When you say "15 seconds startup" time - what sequence is that?

Does the initial frame paint then sit there with the Favorites bar partially painted for a while, then eventually it fills in and then the homepage renders immediately?

Or does the initial frame fully paint quickly (Favorites bar and everything else), then IE sits at "Connecting..." for a long time?

Or is it literally "15 seconds from clicking the blue 'e' to even the initial frame paint, and after that everything is fast (full frame paint, no long Connecting, home page draws immediately".

blowdart
Peek-a-boo

In reply to BruceMorgan

#Jan 28th @ 12:53 PM

Missed me in your reply target.

So I click the quick launch. I see the beginnings of a window between 7-10 seconds later. Another 5 seconds before it's usable.

Even when hitting the quick launch icon when another instance is open took 5-10 seconds to open another window, or clicking a link inside outlook to it opening in a tab in an open instance,