Bug 140768

Summary: loading new page resets scroll position of old page to top
Product: [Applications] konqueror Reporter: Leo Savernik <l.savernik>
Component: khtmlAssignee: Konqueror Bugs <konqueror-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: christian.schrader, martin, mikmach, rdieter, sebastian_ml
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Leo Savernik 2007-01-28 12:32:05 UTC 
Version:            (using KDE KDE 3.5.5)
Installed from:    Compiled From Sources

Since KHTML 3.5.6 there is an annoying behaviour when following links that KHTML resets the scroll position of the original page to the top. This is especially noticeable on slow connections.

Steps to reproduce:
0. Ensure the link target is not in cache.
1. Take any large page with a link at its bottom, e. g. http://www.w3.org/MarkUp/
2. Scroll to the bottom and click a link, e. g. "historical"
3. Then watch out.

Expected results:
As long as khtml stays on the old page (i. e. trying to connect to the new page), the scroll positions stays unchanged. As soon as the new page content is being loaded, the view is cleared and new content being displayed incrementally.

Actual results:
When you click the link, first khtml maintains its scroll position for a while. Then, it *resets* the scroll position of the original page to the top (e. g. such that you can read "HyperText Markup Language (HTML) Home Page") for a short while (depending on your connection speed, you may not perceive this!). Then, after a short period of time, the display is cleared and the real link target starts being rendered.


This behaviour is ultra-annoying because you think the new page has already started loading. When you start reading the "new" page you think, "Hmm, that sounds familiar". In this very moment, the display blanks and the actual new page is loaded.

This severly interrupts the flow of reading, therefore I regard this bug as a severe usability bug.

Note that this bug especially applies to slow lines. It may not be apparent for fast lines.
Comment 1 Leo Savernik 2007-01-28 14:38:41 UTC 
Found the culprit. r617941.

Please see bug 140777 for a detailed analysis.
Comment 2 Philip Rodrigues 2007-01-28 18:14:35 UTC 
Leo, so is one of these two bugs a dupe of the other?
Comment 3 Leo Savernik 2007-01-28 19:33:40 UTC 
Am Sonntag, 28. Januar 2007 schrieb Philip Rodrigues:
> Leo, so is one of these two bugs a dupe of the other?


Well, not quite. While this report is about a concrete bug, bug 140777 is 
about a massive performance degradation. So you can't unanimously say one is 
caused by the other.
Comment 4 Tommi Tervo 2007-01-28 20:57:43 UTC 
*** Bug 139605 has been marked as a duplicate of this bug. ***
Comment 5 Nick Warne 2007-01-28 21:23:32 UTC 
Thank you Leo for the quick hack fix.  This was driving me up the wall.

Nick
Comment 6 Leo Savernik 2007-01-30 18:25:42 UTC 
SVN commit 628618 by savernik:

Reverting r617941. This fixes jumping to the top right before loading a
new page and also fixes page loading time increase.

Attention packagers! Please include this patch in new versions of your
khtml-3.5.6 packages. Web surfing experience can be considered broken
without it.

CCMAIL: kde-packager@kde.org
BUG: 140768
CCBUG: 140777    
CCBUG: 24820


 M  +1 -1      html_documentimpl.cpp  


--- branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp #628617:628618
@@ -222,7 +222,7 @@
 
 void HTMLDocumentImpl::slotHistoryChanged()
 {
-    if ( !m_render )
+    if ( true || !m_render )
         return;
 
     recalcStyle( Force );
Comment 7 Tommi Tervo 2007-02-02 17:11:42 UTC 
*** Bug 141074 has been marked as a duplicate of this bug. ***
Comment 8 Tommi Tervo 2007-04-29 19:42:25 UTC 
*** Bug 144832 has been marked as a duplicate of this bug. ***