Tickets :: Comment on [#5872] unified scroll bars

* Your Email Address
* Spam protection	Enter the letters below: . , __ . ..___.. . \./ / `\|__\| \| \|\/\| \| \__.\| \| \| \| \|
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries