Version: r799768 (using Devel) Installed from: Compiled sources Compiler: gcc 4.3.0 OS: Linux Steps to reproduce (happens every so often - about 5% of the time?): 1. Select a message in the message list 2. Scroll down in the message view 3. Move to another message in the message list Then every so often the new message will be scrolled down the same distance as the previous message, but the scrollbar is at the top. The result is that it is impossible to view the top of the message. After this happens, it stays that way until KMail is quit and reopened.
Created attachment 24477 [details] Screenshot of the behaviour This shows the result of the problem. Note that the fancy headers and the top part of the message are not displayed, despite the scrollbar being at the top.
It appears that using the arrow keys on the keyboard to scroll down (rather than the mouse wheel or scrollbar directly) fixes the issue after the second press (ie: the pane jumps back up to be aligned with the scrollbar).
Hmm, confirmed. It used to work correctly and I'm not aware of any changes of the message viewer. Maybe this could be some KHTML regression, not sure. Might also be KMail's fault though.
Reassigning this to KHTML. I guess this problem is caused by the recent work on the KHTML scrolling code. Might be related to bug 157883.
This problem also affects KNode.
*** Bug 161563 has been marked as a duplicate of this bug. ***
Germain, could you please take a look?
I want to note that this happens 100% of the time (if you scroll all the way to the bottom in the view pane) in the current svn for akregator.
A workaround for this is to start KMail (or the other apps) with QT_NO_FAST_SCROLL=1
This is a showstopper for KMail. Please, can anyone have a look?
I'll have time to investigate after feature freeze (19th).. Some questions that could help : - Is comment #9 accurate? - Does smooth scrolling mode make a difference? (can be programatically set with view()->setSmoothScrollingMode(x) where x is KHTMLView::SSMDisabled or KHTMLView::SSMEnabled) - Does disabling alien widgets change things? (QT_USE_NATIVE_WINDOWS=1) - did this problem appear around the time this bug report was written or long before?
On Wednesday 14 May 2008, Germain Garand wrote: > - did this problem appear around the time this bug report was written > or long before? I can answer this: the bug is relatively new, appear around a month ago, when it was reported. Things were going fine after you fixed the Qt4 regressions in KHTML, but after a while this scrolling bug was introduced.
QT_NO_FAST_SCROLL=1 and QT_USE_NATIVE_WINDOWS=1 both have no effect here. I can't replicate it if I disable smooth scrolling with view()->setSmoothScrollingMode(KHTMLView::SSMDisabled);
Created attachment 24769 [details] Workaround for KMail This one-liner disables smooth scrolling in kmail, which appears to stop the problem occurring.
> This one-liner disables smooth scrolling in kmail, which appears to stop the > problem occurring. Thanks! Please commit this, with a quick comment in the code explaining the reason (with link to this bug report).
SVN commit 808046 by alexmerry: Work-around for a scrolling bug. CCBUG: 161148 M +5 -0 kmreaderwin.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=808046
SVN commit 808123 by uwolfer: also apply workaround for smoothscrolling-issues for Akregator CCBUG:161148 M +3 -0 articleviewer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=808123
On Thursday 15 May 2008, Urs Wolfer wrote: > also apply workaround for smoothscrolling-issues for Akregator I somewhat disagree with this workarounds. That doesn't make the bug go away and any other user of khtml will hit it sooner or later. I just saw an example where similar problem happens with scrolling inside Konqueror. (Sorry, I cannot give the link, it is on a private server). So better fix khtml (or whatever this causes) and - if this will not happen - enable the workaround only in late bet stage, when it is clear that the real solution will not appear in time.
*** Bug 161193 has been marked as a duplicate of this bug. ***
SVN commit 810119 by ggarand: Better tracking/restoration of contents coordinates when performing a smooth scroll. I think these could go out of sync causing #161148, though I can't immediately verify if this patch fixes the issue. Please test... CCBUG: 161148 M +15 -5 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=810119
SVN commit 810426 by uwolfer: Remove workaround again in KMail and Akregator as it seems to work after fix in rev 810119. BUG:161148 M +0 -3 akregator/src/articleviewer.cpp M +0 -6 kmail/kmreaderwin.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=810426