Looks like mouse-wheel events are handled now.

Michael - with the js emulated scrollbar, would it be possible to 
support scroll-wheel events? If we can do that I'd be happy (and 
honestly, the minimal design of the current scrollbar works just fine 
for me).

Yup - exactly what I am saying.  This logic fails if a user moves the 
scrollbar too slowly.  And again - all this is irrelevant (as 
mentioned before) because even if the scrolling part worked, browser 
scrollbars are still broken in Opera - it duplicates any 
pagedown/pageup click with no way to capture and ignore the 
superfluous event - and scrolling using the arrowicons on IE breaks 
once the messagelist exceeds a certain size - the messagelist will 
move by 2 or more messages per click which does not happen on any 
other browser.

I guess what he meant was, to still listen to the scroll events, but 
only fire the request to the server after a timeout, and cancel this 
timeout as soon as there are more scrolling events. But it's well 
possible that this es exactly what you were saying too.

None of them deal with this.  They will trigger multiple parallel 
requests.  For example, Yahoo Mail does this, but apparently the 
reasoning at yahoo is we don't care - we can just throw scores of 
CPU/IMAP power at the server level
This is what we previously did, but position change is irrelevant.  We 
don't want to load a slice until the user releases the mouse button 
(or else you can generate a bunch (easily 10+) parallel requests - and 
since they are all blocking at the server level, the result is that 
the final message slice may take 30+ seconds to load - completely 
unacceptable.
As mentioned previously, my plan is to spruce up the scroll bar 
graphically to make it look nicer (and also add arrow navigation at 
the top and bottom).  But as usual, any help with graphic design 
elements would be gratefully welcomed since I have no skills there.

This is worthless.  It has the exact same issue as already mentioned - 
if you slowly scroll through the list without releasing the scroll 
bar, it will trigger a boatload of parallel requests to the server - 
because as previously mentioned there is no cross-browser method for 
determining when a user releases the mouse when dragging an internally 
created browser scrollbar.

Have you checked out:

http://www.siteartwork.de/livegrid/

Have you checked any of the full-page continuous scrolling 
implementations to see how they deal with this? Can't we do a timeout 
to see if the scroll position has changed (sorry if this is well past 
the point of what's been tried).



I do agree that the difference between the two scrollbars isn't great. 
I don't mind the message list one as much as Jan, but I probably 
haven't used it as much either. The browser's widgets will always be 
preferable for consistency, but internal consistency is probably 
second best.

I couldn't find any other cross-browser compliant scrollbar widget 
(and I looked for about 3 hours), so if you know of one let me know.



But the one thing we definitely can not do is use the browser's 
scrollbar.  There is absolutely no way to make it work cross-browser - 
and it is so bad, even within the same browser on different platforms, 
like FF on Mac vs. Windows/Linux, the behavior is different.  Other 
than FF for Win/Linux, there is no way to determine on any other 
browser when a user stops scrolling.  Without this feature, scrolling 
through any halfway large list of messages (say, 400-500 messages or 
so) pretty much results in having to do 5-10 simultaneous messagelist 
requests, and many of these messagelist requests are overlapping, and 
each blocks the other.  Absolutely kills the server.



Also, the old method simply will not work on any recent version of 
Opera (Opera fires two javascript events instead of one, and there is 
no way to stop either) and IE would break in mailboxes over a certain 
amount of messages (clicking on the down arrow in a large enough 
mailbox would result in the list scrolling down by 2 or more messages 
instead of 1).

To be honest, I am *really*, I mean *really*, unhappy with the message 
list scroll bar. I know you did this as a last resort because there 
were some problems with the old implementation. But we can never get 
nice looking scroll bars this way, because even if it's styled better 
than now, it will never look like the system's/browser's scrollbars.

Is there really no way to implement that with the old (or a different) 
scrollbar widget?

No.  Using a javascript scroll solution for the folder list is 
overkill and would break auto-scrolling of that list.  The better 
solution is to format the scroll bar for the message list nicer, but 
I'm still waiting for help with that (my graphic design skills are 
horrible).

It would be nice to have unified scroll bars in DIMP. At this time 
there are different scroll bars for the message list in the viewport 
and the folderlist in the left menu.