Version: (using KDE Devel) Installed from: Compiled sources play a bit with a page with anchor and static position to reproduce that one. e.g: http://www.w3.org/TR/html401/struct/lists.html#h-10.2 Go back, forward, reload, place cursor in address bar and press enter... seem to be related to the way static background pages is implemented (it needs view()->widget() positioned at 0,0 all the time). Jump probably happens at such an early time that it does not trigger QScrollArea::scrollContentsBy and the widget ends up stuck at some offset.
I can get the page to only render the fixed background, but it is still scrollable. I've seen some other pages that ended up really wrong, but I can't trigger it here.
if I click the link, it works OK. But if I paste the url in a new tab's address bar and press enter, the invalid state is triggered.
(blank page, displaying artifacts when resizing the view, except if you scroll all the way up so that the widget is indeed at 0,0)
Okay, I can trigger it now. It is pretty crazy. When resizing you can end up with the scrollbar rendered streched over the screen. To me it seems as if the page isn't repainted at the new size, and the old buffered image is reused at a wrong size creating streching artifacts. This has to be a wrong interaction with Qt, either a bug in Qt, or a wrongly set flag.
I've traced it. The bug is in the QScrollArea. It has an eventFilter that catches resizeEvents, and performs its own widget->move() on them. This bypases our scrolling system. I think the solution probably requires inheriting from QAbstractScrollArea instead, or finding another way to handle fixed content.
Created attachment 22249 [details] Example patch This patch demonstrates what is wrong. It tries to undo the damage on every resizeEvent. It is however not an effective solution.
> I've traced it. The bug is in the QScrollArea. > > It has an eventFilter that catches resizeEvents, and performs its own > widget->move() on them. ah right, nice catch, I can see it > I think the solution probably requires inheriting from QAbstractScrollArea > instead, or finding another way to handle fixed content. well if it's in an eventFilter, we can either catch the event in our own filter and reimplement the scrollbar adjustment, or we can undo the bogus move as you suggest. The latter looks like a workable solution. It's not like there is any performance problem with moving the widget within a resize event. > This patch demonstrates what is wrong. It tries to undo the damage on every > resizeEvent. It is however not an effective solution. 'not effective' as in not fully working? I think it just misses a similar check in scrollContentsBy() as there seem to be also a race condition sometimes preventing the initial move(0,0) from happening.
There is indeed a race somewhere during loading and gotoAnchor. I know of a semi-related bug, that is unrelated to fixed content. When using a site like slashdot.org, and clicking on links to comments, Konqueror will often load the link in an odd state. Basically if the anchor is one the first visible page, the viewport is sometimes moved instead of the content, this way the viewport doesn't fill the screen, so the lower part of the screen is black, but the content scrolling correctly at the top. Example: http://slashdot.org/comments.pl?sid=373791&threshold=0&commentsort=0&mode=thread&pid=21514445#21514969 This race condition I believe might be the same that inhibits my patch. I would prefer to solve it generally.
SVN commit 743928 by carewolf: Work-around that QScrollArea hasn't fully abstracted the scrolling mechanism, and sometimes scrolls without our intervention. * Fixes another showshopping bug. BUG: 153033 M +21 -17 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=743928
Bug is still open. The symptoms are just reduced
Created attachment 22621 [details] New patch Patch fixing even more cases of this bug. I can still trigger misjumps every now and then though.
do you have some page where it's reproducible? I didn't see such problems since you closed. the strange thing is your patch basically says scrollContentsBy does not get called. I can't see how this can happen as the scrollbar's valueChanged() signal is wired to scrollContentsBy from as soon as QAbstractScrollArea's constructor. did you try to assert(!signalsBlocked()) from in there?
Try the slashdot link. Generally clicking on any early comment in a thread will result in a half painted page.
mmh, no I can't reproduce there.
Works fine for me using 4.0.3.
yes, this is fixed now