Version: r799768 (using Devel)
Installed from: Compiled sources
Compiler: gcc 4.3.0
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).
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
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
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
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
> 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.
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
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.
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.
M +0 -3 akregator/src/articleviewer.cpp
M +0 -6 kmail/kmreaderwin.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=810426