Wed, 08 Apr 2026 17:39:12 +0000 https://bugs.horde.org/ticket/5872 unified scroll bars 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. Wed, 07 Nov 2007 22:53:37 +0000 https://bugs.horde.org/ticket/5872#t38489 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). Fri, 09 Nov 2007 04:08:58 +0000 https://bugs.horde.org/ticket/5872#t38501 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? Fri, 09 Nov 2007 11:42:59 +0000 https://bugs.horde.org/ticket/5872#t38508 > 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? 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). Fri, 09 Nov 2007 17:16:28 +0000 https://bugs.horde.org/ticket/5872#t38518 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. Sat, 24 Nov 2007 22:33:52 +0000 https://bugs.horde.org/ticket/5872#t38991 Have you checked out: http://www.siteartwork.de/livegrid/ Fri, 14 Dec 2007 17:06:37 +0000 https://bugs.horde.org/ticket/5872#t39910 > Have you checked out: > http://www.siteartwork.de/livegrid/ 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. Sat, 22 Dec 2007 06:55:25 +0000 https://bugs.horde.org/ticket/5872#t40208 > Have you checked any of the full-page continuous scrolling > implementations to see how they deal with this? 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 > 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). 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. > 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. 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. Sat, 22 Dec 2007 07:01:23 +0000 https://bugs.horde.org/ticket/5872#t40211 >> 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). > > 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. 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. Sat, 22 Dec 2007 09:07:06 +0000 https://bugs.horde.org/ticket/5872#t40215 > 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. 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. Wed, 26 Dec 2007 06:46:17 +0000 https://bugs.horde.org/ticket/5872#t40360 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). Tue, 04 Mar 2008 20:27:25 +0000 https://bugs.horde.org/ticket/5872#t43374 Looks like mouse-wheel events are handled now. Wed, 16 Apr 2008 18:05:48 +0000 https://bugs.horde.org/ticket/5872#t44673