Summary: | Scrolling is completely broken in trunk | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | András Manţia <amantia> |
Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dariopnc, makosoft |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
András Manţia
2008-02-15 19:00:46 UTC
It wasn't completely correct what I wrote: pgup/pgdn is also broken, but it is not that visible. bugs.kde.org is a good testpage. Some updates: - scrolling works OK when you start Konqueror on bugs.kde.org - open the following site: http://www.rdi-board.com/forumdisplay.php?f=9 . As I run on 64bit, I disabled plugins (for real, Enable plugins globally is not checked, and I removed the path to /usr/lib64/browser-plugins and run a scan so no plugins are found). I get the Missing Plugin dialog for Shockwave Flash. Click on Do Not Download. - scrolling is really broken now - if I open a new tab, scrolling is broken on bugs.kde.org as well. i experienced it when a page with a flash object is rendered (via nsplugin) http://it.youtube.com/watch?v=GrGOmGMYDqE What I was doing: 1. go to a website (kde-look.org), scrolling works fine 2. go to a website (pollycoke.net) with a flash object to be loaded via nsplugin (the object is the big gray square) 3. go back to the first URL (kde-look.org) scrolling is broken 4. go to another url (liceotosi.va.it) to show another case of broken scrolling The problem is that I see this behavior also in KMail (which uses khtml to display the mail), and there is no flash involved for sure. Same here - KDE trunk (couple of days old). Not only does using PgUp and PgDown not work quite correctly, clicking on the scrollbar doesn't always either. Specifically, the last time I scroll down using this method on an affected page (which seems to be pretty much everything), the area at the top that should show the part of the page visible before scrolling isn't updated correctly. A similar thing happens with PgUp and PgDown - they always scroll just under a full page, so there's an area of the page at the bottom or top of the window respectively that was visible before hitting the key and doesn't get redrawn properly/at all. I'm using KDE trunk and qt-copy from a couple of days ago, as well as xorg-server 1.4.0.90-r3 (Gentoo patched version) and Nouveau, which would probably exclude me from reporting the issue myself. does it happen when starting konqueror with QT_USE_NATIVE_WINDOWS=1 konqueror (in a console)? Actually I use this for a few days, because of bug #157659, and I did not see the problem since. I'll comment here if it happens again. allright... meanwhile I'll disable alien widgets in KHTML for the time being. We have basically no use for those anyway and we have enough Qt bugs to deal with elsewhere. SVN commit 783986 by ggarand: disable alien widgets on khtmlview while they break scroll blitting CCBUG: 157883 M +6 -0 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=783986 Unless there were other KHTML commits to fix bug 158664, I think that disabling of alien widgets fixed it. András: no, it's unrelated, I disabled form widgets drawing optimizations in another commit, to cope with the buggy state of qt-copy (r783807). It looks like I'll have to revert the disabling of alien widgets anyway, as it triggers other Qt scrolling bugs in kopete. Mixing alien and native widgets doesn't seem trivial at all. One will have to use QT_USE_NATIVE_WINDOWS=1 for the time beeing... all right, might not need to revert eventually. I've been working on a big scrolling optimization I had in mind for a very long time, and it seem it has the nice side effect of keeping Qt happy in all situations... SVN commit 784703 by ggarand: Large optimization of scrolling for pages containing "position: fixed" objects. .replace the dumb approach of repainting the whole page always, by collecting fixed regions, repainting them individually, then blit-scrolling the remaining surface. .also maintain a tighter count of fixed objects, so that changes of styles might trigger a switch from static to blitting (i.e. fast) background. .consequently, go all the way to using QWidget::scroll() instead of native QWidget::move() for scrolling, so as to avoid the unescapable flicker when switching from a method to the other. QWidget::scroll is - I believe, a tad slower, but not significantly so, and the gain in overall browsing smoothness is very satisfactory. -change of scrolling method conveniently allows to avoid the serious scrolling bugs in 4.4 beta, making it possible to remove the disabling of alien widgets, which in turn should fix the problems Roman encountered in Kopete. CCMAIL: kedgedev@centrum.cz CCBUG: 157883 M +1 -11 css/cssstyleselector.cpp M +97 -52 khtmlview.cpp M +4 -1 khtmlview.h M +1 -1 rendering/render_block.h M +16 -0 rendering/render_canvas.cpp M +1 -0 rendering/render_canvas.h M +2 -0 rendering/render_layer.cpp M +26 -1 rendering/render_object.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=784703 SVN commit 784727 by ggarand: automatically merged revision 783986: disable alien widgets on khtmlview while they break scroll blitting CCBUG: 157883 M +6 -0 khtmlview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=784727 This is fixed now, the new scrolling bug is 161148. Recently (r954446) I saw it again on two sites, in a short time-frame. Nothing else changed on my system, but my trunk checkout was updated (last update was ~10 days ago). I don't reopen (yet), I'll wait to see it again, but anyway I wanted to let you know about it. |