Bug 57360 - [testcase] URLs with anchor - sometimes the position is not moved to the anchor
Summary: [testcase] URLs with anchor - sometimes the position is not moved to the anchor
Status: REOPENED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 52608 52671 63511 64956 67398 77808 80600 84564 85786 87208 87486 100901 140680 141075 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-04-17 09:30 UTC by Lubos Lunak
Modified: 2021-03-21 00:25 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
New testcase (8.11 KB, text/html)
2004-06-03 21:31 UTC, Michael Nottebrock
Details
Test case where no anchor is working (21.67 KB, text/html)
2004-06-16 00:17 UTC, Joachim Ansorg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lubos Lunak 2003-04-17 09:30:13 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

Go e.g. to http://kde.org/info/3.1.1.php#binary or http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.3 . Wait for the page to load and press repeatedly F5 to reload. Sometimes (or better said, almost in all cases), after the rendering is finished, the page is not scrolled to the anchor, but top of the page stays shown.
Comment 1 Maksim Orlovich 2003-06-14 18:08:12 UTC
*** Bug 52608 has been marked as a duplicate of this bug. ***
Comment 2 Maksim Orlovich 2003-06-14 18:08:52 UTC
52608 suggests direct entering of a link with an anchor in the location combo is 
also broken 
Comment 3 Joseph Reagle 2003-06-16 15:56:44 UTC
Subject: Re:  Problems with dereferencing and displaying fragment identifiers

On Saturday 14 June 2003 10:20, kl@3dots.de wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> http://bugs.kde.org/show_bug.cgi?id=52671
> ------- Additional Comments From kl@3dots.de  2003-06-14 16:20 -------
> dup of bug 52608

Since 52608 is marked a dup as well, it'd be better perhaps to reference:
  http://bugs.kde.org/show_bug.cgi?id=57360
to which I  will move my votes.

Comment 4 Maksim Orlovich 2003-08-03 17:25:28 UTC
*** Bug 62057 has been marked as a duplicate of this bug. ***
Comment 5 Maksim Orlovich 2003-08-31 17:05:11 UTC
*** Bug 63511 has been marked as a duplicate of this bug. ***
Comment 6 Moritz Moeller-Herrmann 2003-09-12 12:21:49 UTC
Bug still present in KDE-CVS. Trigger seems to be timing dependent? I get the top of the page in 
maybe 1 / 10 reloads. 
Comment 7 Thiago Macieira 2003-09-26 05:01:06 UTC
*** Bug 64956 has been marked as a duplicate of this bug. ***
Comment 8 Tommi Tervo 2003-11-01 17:35:39 UTC
*** Bug 52671 has been marked as a duplicate of this bug. ***
Comment 9 Tommi Tervo 2003-11-06 15:30:25 UTC
*** Bug 67398 has been marked as a duplicate of this bug. ***
Comment 10 Stephan Binner 2003-12-01 16:26:52 UTC
Subject: kdelibs/khtml

CVS commit by binner: 

Don't jump to an anchor right after parsing is finished but when all content 
is loaded and style sheets are applied. Patch was tested by Laurent Montel.
CCMAIL: 57360-done@bugs.kde.org


  M +5 -5      khtml_part.cpp   1.946


--- kdelibs/khtml/khtml_part.cpp  #1.945:1.946
@@ -1797,8 +1797,4 @@ void KHTMLPart::slotFinishedParsing()
   d->m_view->restoreScrollBar();
 
-  if ( !m_url.encodedHtmlRef().isEmpty() )
-    if ( !gotoAnchor( m_url.encodedHtmlRef()) )
-       gotoAnchor( m_url.htmlRef() );
-
   checkCompleted();
 }
@@ -1989,4 +1985,8 @@ void KHTMLPart::checkCompleted()
   setJSDefaultStatusBarText(QString::null);
 
+  if ( !m_url.encodedHtmlRef().isEmpty() )
+    if ( !gotoAnchor( m_url.encodedHtmlRef()) )
+       gotoAnchor( m_url.htmlRef() );
+  
 #ifdef SPEED_DEBUG
   kdDebug(6050) << "DONE: " <<d->m_parsetime.elapsed() << endl;


Comment 11 Roman Fietze 2004-03-11 11:05:15 UTC
This bug is still present in 3.2.1. I ran the page through validator.w3.org/ and checked the page with MozillaFirebird. Both tell me the page is corrct and jump to the <a name="whatever"></a> statement, konqueror does not.

The page was produced using Doxygen 3.1.5, the source listing in the source browser. Available at your request.
Comment 12 Joseph Reagle 2004-03-11 15:09:13 UTC
Yes, I can confirm it is in 3.2.1 Debian unstable for the tronche URL above.
Comment 13 Tommi Tervo 2004-03-17 09:44:03 UTC
*** Bug 77808 has been marked as a duplicate of this bug. ***
Comment 15 Martin Koller 2004-06-03 14:18:29 UTC
The above mentioned testcase seems no longer valid, but I have the same problem still with CVS from a few days ago (usually when browsing through the _local_ Qt documentation)
Comment 16 Joseph Reagle 2004-06-03 14:25:50 UTC
On Thursday 03 June 2004 14:18, Martin Koller wrote:
> ------- Additional Comments From m.koller surfeu at  2004-06-03 14:18
> ------- The above mentioned testcase seems no longer valid, but I have
> the same problem still with CVS from a few days ago (usually when
> browsing through the _local_ Qt documentation)

Yep, I notice it quite a lot with KDE 3.4. For example "hinted" at
  http://goatee.net/2004/05#_22sa
has a link to:
  http://goatee.net/2002/07.html#_08mo
which doesn't work correctly in Konqueror. (It stays at the top, I have to 
go to the address bar and hit return on that address to get the view to 
move correctly.)

Comment 17 Michael Nottebrock 2004-06-03 21:31:55 UTC
Created attachment 6243 [details]
New testcase
Comment 18 Michael Nottebrock 2004-06-03 21:37:48 UTC
It seems the anchorhandling suffers from an off by one bug: Konqueror 3.2.2 will jump to the previous-of-the-specified-anchor if specified in the URL:

http://people.fruitsalad.org/lofi/testcase.html#a3 <- Anchor 2 is visible

Also, if you reduce the testcase to just one anchor, Konqueror will stay at the top of the page.

Konqueror 3.2.3 (packager prerelease tarballs, I'm a packager) adds a regression to that: It does not jump to the anchors at all after the initial load of the page, it remains at the top and only jumps to the the previous-of-the-specified-anchor after hitting return in the URL bar a second time.
Comment 19 Piotr Szymański 2004-06-03 21:52:01 UTC
*** Bug 80600 has been marked as a duplicate of this bug. ***
Comment 20 Joachim Ansorg 2004-06-16 00:17:34 UTC
Created attachment 6376 [details]
Test case where no anchor is working 

This is a HTML file to show that anchors are not working at all if inline
elements are used.

The only anchor is "a1" and it is on the last word of the document. Loading
test.html#a1 in konqueror does not make Konqueror jump to the position.
After replacing all spans by divs it works usually.

The HTML file is valid XHTML (checked by the W3C validator).

(Using KDE 3.2.3 and Qt 3.2.3)

Thanks for the great work.
Comment 21 Jeroen Wijnhout 2004-06-17 11:15:39 UTC
I'm working on a patch, please hold...

best,
Jeroen
Comment 22 Jeroen Wijnhout 2004-06-17 21:59:14 UTC
I've applied a patch to KDE HEAD, it fixes the bug for me. People who run KDE HEAD, please update kdelibs/khtml, test and report back.

thanks,
Jeroen
Comment 23 Martin Koller 2004-06-19 16:41:14 UTC
I'm using it. It works often, but not always.
E.g. if I'm using swat (http://localhost:901/shares) then select a share and open the help for "valid users" (URL = http://localhost:901/swat/help/smb.conf.5.html#VALIDUSERS) konqi opens a new window but instead showing me the given section, it shows the beginning of the page. Pressing Enter again in the address field works.

But having the help window already open, the VALIDUSERS link does work - the already open window jumps to the desired anchor.

So I think it has something to do with the start of a new window (kind of timing problem?)
Comment 24 Scott Wheeler 2004-06-22 16:12:18 UTC
*** Bug 57819 has been marked as a duplicate of this bug. ***
Comment 25 Tommi Tervo 2004-07-06 14:48:43 UTC
*** Bug 84564 has been marked as a duplicate of this bug. ***
Comment 26 Jon Dowland 2004-07-19 17:53:24 UTC
Testcase: http://jon.dowland.name/code/bugs/konqueror/4/#three
I do not experience off-by-one behaviour; there are three targets in that page labelled one, two and three. If the off-by-one behaviour was correct, I would expect a first visit to that page to present the second target but it presents the first at the top of the page.

The behaviour I witness is therefore simply ignoring relative targets within pages on the first load. A reload of the page will always jump to the anchor.

Present in debian/sid 3.2.2-1 Mon Jul 19 16:53:05 BST 2004
Comment 27 Stephan Kulow 2004-07-25 13:15:25 UTC
*** Bug 85786 has been marked as a duplicate of this bug. ***
Comment 28 Christian Loose 2004-08-19 10:30:09 UTC
*** Bug 87486 has been marked as a duplicate of this bug. ***
Comment 29 Germain Garand 2004-08-27 19:54:17 UTC
CVS commit by ggarand: 

 - more accurate completed() signal.
 - anchor jumps: keep jumping at least while parsing, but not any longer.

CCMAIL: 57360@bugs.kde.org


  M +14 -0     ChangeLog   1.281
  M +16 -14    khtml_part.cpp   1.1021
  M +30 -1     khtmlview.cpp   1.663
  M +1 -1      khtmlview.h   1.213



Comment 30 Germain Garand 2004-08-28 16:41:25 UTC
CVS commit by ggarand: 

more jump-to-anchor massaging

- adjust get[UpperLeft|LowerRight]Corner to use inlineYPos
  when the reference object is text (see #57360 c.#17)

- common quirk: "top" and "" anchors mean top of document.

CCMAIL: 57360@bugs.kde.org
  


  M +4 -0      ChangeLog   1.282
  M +7 -1      khtml_part.cpp   1.1022
  M +13 -9     xml/dom_nodeimpl.cpp   1.237


--- kdelibs/khtml/ChangeLog  #1.281:1.282
@@ -7,4 +7,5 @@
         position on reload, avoid jumping to anchors.
         (gotoAnchor): keep jumping at least while we are parsing.
+        (gotoAnchor): "top" and "" anchors mean top of document.
 
         (checkCompleted): entrust the view to emit completed on our behalf
@@ -13,4 +14,7 @@
         * khtmlview.{cpp,h}: ditto
 
+        * xml/dom_nodeimpl.cpp (getUpperLeftCorner/getLowerRightCorner):
+        use inlineYPos for text objects (#57360 c.#17).
+
 2004-08-27  Leo Savernik  <l.savernik@aon.at>
 

--- kdelibs/khtml/khtml_part.cpp  #1.1021:1.1022
@@ -2325,5 +2325,11 @@ bool KHTMLPart::gotoAnchor( const QStrin
   }
 
-  if(!n) {
+  // Implement the rule that "" and "top" both mean top of page as in other browsers.
+  bool quirkyName = !n && !d->m_doc->inStrictMode() && (name.isEmpty() || name.lower() == "top");
+  
+  if (quirkyName) {
+      d->m_view->setContentsPos(0, 0);
+      return true;
+  } else if (!n) {
       kdDebug(6050) << "KHTMLPart::gotoAnchor node '" << name << "' not found" << endl;
       return false;

--- kdelibs/khtml/xml/dom_nodeimpl.cpp  #1.236:1.237
@@ -1351,9 +1351,11 @@ bool NodeBaseImpl::getUpperLeftCorner(in
         if((o->isText() && !o->isBR()) || o->isReplaced()) {
             o->container()->absolutePosition( xPos, yPos );
-            if (o->isText())
-                xPos += static_cast<RenderText *>(o)->minXPos();
-            else
+            if (o->isText()) {
+                xPos += o->inlineXPos();
+                yPos += o->inlineYPos();
+            } else {
                 xPos += o->xPos();
             yPos += o->yPos();
+            }
             return true;
         }
@@ -1393,9 +1395,11 @@ bool NodeBaseImpl::getLowerRightCorner(i
         if((o->isText() && !o->isBR()) || o->isReplaced()) {
             o->container()->absolutePosition(xPos, yPos);
-            if (o->isText())
-                xPos += static_cast<RenderText *>(o)->minXPos() + o->width();
-            else
-                xPos += o->xPos()+o->width();
-            yPos += o->yPos()+o->height();
+            if (o->isText()) {
+                xPos += o->inlineXPos() + o->width();
+                yPos += o->inlineYPos() + o->height();
+            } else {
+                xPos += o->xPos() + o->width();
+                yPos += o->yPos() + o->height();
+            }
             return true;
         }


Comment 31 Germain Garand 2004-08-28 17:01:26 UTC
I can't reproduce any issue mentioned or linked here now.
Anyone care to confirm?
Comment 32 Jeroen Wijnhout 2004-08-28 17:03:45 UTC
If you are going to backport this to KDE 3.3, then I will check ;-)
Comment 33 Germain Garand 2004-08-28 17:15:33 UTC
this is the point of having it double checked, you blackmailer :)
Comment 34 Piotr Szymański 2004-08-28 18:08:20 UTC
Hi,
Germain Garand (Saturday 28 of August 2004 17:15):
> this is the point of having it double checked, you blackmailer :)
I would check it, but im afraid to update kdelibs after those kdemm changes. 
Maybe a oaptch for kde 3.3 ?
Comment 35 Bart Verwilst 2004-08-28 19:19:26 UTC
If we could have a patch against kde 3.3.0 release, i'll test too! :)
Comment 36 Tommi Tervo 2004-08-30 10:26:09 UTC
Wfm. Many thanks to Germain. (using 3_3_branch kde, but khtml is from HEAD).
Comment 37 Germain Garand 2004-09-04 15:30:39 UTC
*** Bug 87208 has been marked as a duplicate of this bug. ***
Comment 38 Germain Garand 2004-09-08 20:08:52 UTC
CVS commit by ggarand: 

backport jump-to-anchor fixes

CCMAIL: 57360-done@bugs.kde.org


  M +14 -4     khtml_part.cpp   1.1015.2.3
  M +13 -9     xml/dom_nodeimpl.cpp   1.236.2.1


--- kdelibs/khtml/xml/dom_nodeimpl.cpp  #1.236:1.236.2.1
@@ -1351,9 +1351,11 @@ bool NodeBaseImpl::getUpperLeftCorner(in
         if((o->isText() && !o->isBR()) || o->isReplaced()) {
             o->container()->absolutePosition( xPos, yPos );
-            if (o->isText())
-                xPos += static_cast<RenderText *>(o)->minXPos();
-            else
+            if (o->isText()) {
+                xPos += o->inlineXPos();
+                yPos += o->inlineYPos();
+            } else {
                 xPos += o->xPos();
             yPos += o->yPos();
+            }
             return true;
         }
@@ -1393,9 +1395,11 @@ bool NodeBaseImpl::getLowerRightCorner(i
         if((o->isText() && !o->isBR()) || o->isReplaced()) {
             o->container()->absolutePosition(xPos, yPos);
-            if (o->isText())
-                xPos += static_cast<RenderText *>(o)->minXPos() + o->width();
-            else
-                xPos += o->xPos()+o->width();
-            yPos += o->yPos()+o->height();
+            if (o->isText()) {
+                xPos += o->inlineXPos() + o->width();
+                yPos += o->inlineYPos() + o->height();
+            } else {
+                xPos += o->xPos() + o->width();
+                yPos += o->yPos() + o->height();
+            }
             return true;
         }

--- kdelibs/khtml/khtml_part.cpp  #1.1015.2.2:1.1015.2.3
@@ -576,4 +576,5 @@ bool KHTMLPart::openURL( const KURL &url
     args.yOffset = d->m_view->contentsY();
     d->m_extension->setURLArgs(args);
+    disconnect(d->m_view, SIGNAL(finishedLayout()), this, SLOT(gotoAnchor()));
     connect(d->m_view, SIGNAL(finishedLayout()), this, SLOT(restoreScrollPosition()));
   }
@@ -2242,7 +2243,10 @@ void KHTMLPart::setUserStyleSheet(const 
 void KHTMLPart::gotoAnchor()
 {
+  if ( !d->m_doc || !d->m_doc->parsing() ) {
   disconnect(d->m_view, SIGNAL(finishedLayout()), this, SLOT(gotoAnchor()));
-  if ( !gotoAnchor( m_url.encodedHtmlRef()) )
-      gotoAnchor( m_url.htmlRef() );
+  }
+
+  if ( !gotoAnchor(m_url.encodedHtmlRef()) )
+      gotoAnchor(m_url.htmlRef());
 }
 
@@ -2262,5 +2266,11 @@ bool KHTMLPart::gotoAnchor( const QStrin
   }
 
-  if(!n) {
+  // Implement the rule that "" and "top" both mean top of page as in other browsers.
+  bool quirkyName = !n && !d->m_doc->inStrictMode() && (name.isEmpty() || name.lower() == "top");
+
+  if (quirkyName) {
+      d->m_view->setContentsPos(0, 0);
+      return true;
+  } else if (!n) {
       kdDebug(6050) << "KHTMLPart::gotoAnchor node '" << name << "' not found" << endl;
       return false;


Comment 39 Christoph Thielecke 2004-11-29 05:46:17 UTC
It still dont work correctly. this link i tried with Konqueror from 3.3.1 with rpm from SuSE FTP on SuSE 9.2:
http://www.pyramid.de/pyforum/viewtopic.php?p=3921&sid=9bbd24091c4e8c0cdfabbc81d2b7158a#3921
Comment 40 boris 2004-12-12 22:22:37 UTC
Hi. I am running KDE 3.3.2 with QT-3.3.3. I have compiled the above with GCC-3.4. I am experiencing this anchor bug in this latest release. According to the gentoo (don't hit me ;)) forums, I am not the only one. http://forums.gentoo.org/viewtopic.php?t=263584
Although other people reported it working fine for them.

I have had the bug before (in I believe KDE-3.2.3), but the bug wasn't there in my build of KDE-3.3.0.

I'll be happy to test out some things if it is needed. I can be reached at borizz _AT_ g m a i l DOTCOM
Comment 41 Richard Fujimoto 2004-12-12 22:59:40 UTC
I'm also affected by this... can this bug be re-opened?

Currently running kde 3.3.2 with qt 3.3.3
Comment 42 Germain Garand 2004-12-12 23:48:31 UTC
> can this bug be re-opened?

I'm afraid not. It's indeed a sore 3.3.2 regression
but it's already fixed in CVS (see #94783)
;(
Comment 43 Germain Garand 2004-12-13 16:40:26 UTC
CVS commit by ggarand: 

backport anchor-jumping regression fix
CCBUG: 57360, 94783


  M +19 -33    khtml_part.cpp   1.1015.2.14
  M +2 -5      khtml_part.h   1.262.2.4
  M +2 -0      khtmlpart_p.h   1.54.2.2



Comment 44 Jon Dowland 2004-12-14 12:54:22 UTC
Thanks for your hard work, Germain!

Should bug #94783 not be merged with this one - or am I missing something?
Comment 45 Mathias Homann 2005-01-12 14:38:21 UTC
does this also affect the part where directly going to an url like "http://foo.bar/baz#baf"? or should i open a new one for that?
Comment 46 Jon Dowland 2005-01-12 14:56:41 UTC
On Wed, Jan 12, 2005 at 01:38:38PM -0000, Mathias Homann wrote:
 
> ------- Additional Comments From admin eregion de  2005-01-12 14:38 -------
> does this also affect the part where directly going to an url like "http://foo.bar/baz#baf"? or should i open a new one for that?

not for me

Qt: 3.3.3
KDE: 3.3.1
Konqueror: 3.3.1

Comment 47 Mathias Homann 2005-01-12 15:58:43 UTC
for me it works, or it does not. seemingly on a random basis.
what i have here is:

1. a mail containing one or more urls with anchors (spamcop submission notices)
2. a small shell script to extract all those urls when i tell kmail to pipe the mail through the script, and call konqueror via dcop for each of those urls

what i get is one or more konqueror windows with those urls loaded, and sometimes jumping to the anchor works, and sometimes it doesnt.


and believe me, when you get 150++ spams per day, you want to automate it as much as possible...
Comment 48 Oliver Fischer 2005-02-22 08:26:37 UTC
Please reopen this bug. It does not work on my system. I have a large docbook document and if I navigate through the document, konqueror never jumps to the given anchor.
Comment 49 Maksim Orlovich 2005-03-06 21:26:01 UTC
*** Bug 100901 has been marked as a duplicate of this bug. ***
Comment 50 Jens 2005-03-09 13:39:45 UTC
Hi everybody,

I was just about to report this too ;)

For me (KDE 3.3.2, SuSE 9.2 "unofficial" RPMs) jumping to an anchor 

- NEVER works by clicking on a link or reloading (F5)
- ALWAYS works by clicking into the URL input field so the cursor appears there and pressing ENTER.

Testcases: lots of 'em in just about any discussion forum (e.g. drupal.org).

Thanks for looking into this, it'll get my vote!

Jens
Comment 51 pierre 2005-08-13 11:46:32 UTC
Hi

This bug is still present for me in KDE 3.4.2...
Here is a pictures galery where I use anchors. It works perfectly within Firefox and opera, but not in konqueror : http://clem.robertlan.eu.org/trains/galeries/ter_z24500/galerie.php?photo=img_1181_1.jpg#24

So I think this bug should be reopened :/
Comment 52 alan 2006-01-15 21:54:53 UTC
I have just been developing an application in which the page has LOTS of anchors, and the URL requesting the page has the anchor encoded in it.

Konqueror jumps partially towards tje anchor when it is in the URL, but it does not getting to the exact place where the anchor is. (Firefox works perfectly, just so that I know its not my application).

this is with 3.5.0

Comment 53 Mathias Homann 2006-01-17 08:02:08 UTC
this bug should be reopened. it is still present in 3.5.0 
Comment 54 Bram Schoenmakers 2007-01-26 22:07:24 UTC
Reopening.
Comment 55 Bram Schoenmakers 2007-01-26 22:07:49 UTC
*** Bug 140680 has been marked as a duplicate of this bug. ***
Comment 56 Tommi Tervo 2007-02-02 17:15:37 UTC
*** Bug 141075 has been marked as a duplicate of this bug. ***
Comment 57 esigra 2008-02-27 18:58:17 UTC
Some of the testcases presented above seem to work with Konqueror now, and others are broken links nowadays. But here is a link that fails today, with Konqueror 3.5.8. Others have confirmed it with 3.5.9.

http://websvn.kde.org/tags/KDE/3.5.9/kdebase/kcontrol/energy/energy.cpp?annotate=774532#l343

Since the page is on kde.org, there is no one else to blame. Either the bug is in the browser (likely) or in the website.

Comment 58 Michael Leupold 2008-04-06 06:16:57 UTC
Confirmed on trunk r793971.
Some testcases seem to work others not. name-anchors seem more likely to work than id-anchors.
Comment 59 Dario Andres 2009-01-04 22:11:19 UTC
Still valid here using:

Qt: 4.4.3 + qt-copy-patches-889120
KDE: 4.1.87 (KDE 4.1.87 (KDE 4.2 >= 20090101))
kdelibs svn rev. 905636 / kdebase svn rev. 905636
on ArchLinux x86_64 - Kernel 2.6.27.10

If after the page is completely loaded (and scrolled to the anchor), you scroll to another position, the next reload will bring you to that position instead to the anchor one.

Tested with:
http://websvn.kde.org/tags/KDE/3.5.9/kdebase/kcontrol/energy/energy.cpp?annotate=774532#l343 
and
http://jmtd.net/computing/software/bugs/konqueror/4/#three

Comment 60 Michal Hlavinka 2009-03-13 12:27:05 UTC
this still exists in 4.2.1

I can reproduce this with documentation created by doxygen (html with frames) - middle click on some class/method documentation (link containing anchor). Every time position is wrong. Going to location toolbar and pressing enter or 'Go' button fixes position in the page.
Comment 61 Allan Sandfeld 2010-03-27 21:22:01 UTC
Comment #59 does not describe a bug, but intended behaviour. The position you are currently viewing is preserved across reloads.

The test-case from comment #57 is working fine here on KDE 4.4
Comment 62 Justin Zobel 2021-03-21 00:25:39 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.