Version: 1.11.0 (using 4.2.00 (KDE 4.2.0), Arch Linux) Compiler: gcc OS: Linux (i686) release 2.6.28-ARCH Steps to Reproduce: Open a received e-mail in the message view window, or the preview pane. Press Shift+{up|down}, and the message scrolls. Now press Shift+[opposite direction]. Expected Outcome: One should be able to stop/change the direction of the scrolling in this way. Actual Outcome: The scroll speed becomes minimal, but still nonzero, and also becomes jerky. Scrolling can be stopped by spinning the mouse wheel, or when it reaches the top or bottom of the message. I hadn't encountered this feature at all before today, but I would assume that it shouldn't be behaving in this fashion. Notes: I don't imagine this should make a difference, but FWIW, I'm running KMail embedded into Kontact
Confirmed in kmail 1.11.90 (kde 4.2.62) using kmail alone.
Duplicate of bug #119281 ?
Not a duplicate of that bug. This is not about drawing speed. This bug is about Shift up and shift down keys that never stop and never change direction. It looks like shift up/down is reducing actual scroll speed by half, but never stops.
Actually this is a KHTML bug. it does not stop its internal scrolling timer when one calls scrollBy() programmatically. I sent a patch for review to the maintainers.
SVN commit 1016875 by mkoller: BUG: 184273 Stop the internal scrolling timer when scrolling via the scrollBy() API method M +2 -0 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1016875
SVN commit 1020459 by mkoller: Backport r1016875 by mkoller from trunk to the 4.3 branch: CCBUG: 184273 Stop the internal scrolling timer when scrolling via the scrollBy() API method M +2 -0 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1020459