Bug 57360

*** Bug 52608 has been marked as a duplicate of this bug. ***

52608 suggests direct entering of a link with an anchor in the location combo is 
also broken 

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.

*** Bug 62057 has been marked as a duplicate of this bug. ***

*** Bug 63511 has been marked as a duplicate of this bug. ***

Bug still present in KDE-CVS. Trigger seems to be timing dependent? I get the top of the page in 
maybe 1 / 10 reloads. 

*** Bug 64956 has been marked as a duplicate of this bug. ***

*** Bug 52671 has been marked as a duplicate of this bug. ***

*** Bug 67398 has been marked as a duplicate of this bug. ***

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;

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.

Yes, I can confirm it is in 3.2.1 Debian unstable for the tronche URL above.

*** Bug 77808 has been marked as a duplicate of this bug. ***

Testcase from #77808
http://developer.kde.org/documentation/library/cvs-api/kdecore/html/kstandarddirs_8cpp-source.html#l00514

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)

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.)

Created attachment 6243 [details]
New testcase

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.

*** Bug 80600 has been marked as a duplicate of this bug. ***

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.

I'm working on a patch, please hold...

best,
Jeroen

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

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?)

*** Bug 57819 has been marked as a duplicate of this bug. ***

*** Bug 84564 has been marked as a duplicate of this bug. ***

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

*** Bug 85786 has been marked as a duplicate of this bug. ***

*** Bug 87486 has been marked as a duplicate of this bug. ***

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

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;
         }

I can't reproduce any issue mentioned or linked here now.
Anyone care to confirm?

If you are going to backport this to KDE 3.3, then I will check ;-)

this is the point of having it double checked, you blackmailer :)

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 ?

If we could have a patch against kde 3.3.0 release, i'll test too! :)

Wfm. Many thanks to Germain. (using 3_3_branch kde, but khtml is from HEAD).

*** Bug 87208 has been marked as a duplicate of this bug. ***

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;

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

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

I'm also affected by this... can this bug be re-opened?

Currently running kde 3.3.2 with qt 3.3.3

> 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)
;(

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

Thanks for your hard work, Germain!

Should bug #94783 not be merged with this one - or am I missing something?

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?

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

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...

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.

*** Bug 100901 has been marked as a duplicate of this bug. ***

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

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 :/

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

this bug should be reopened. it is still present in 3.5.0 

Reopening.

*** Bug 140680 has been marked as a duplicate of this bug. ***

*** Bug 141075 has been marked as a duplicate of this bug. ***

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.

Confirmed on trunk r793971.
Some testcases seem to work others not. name-anchors seem more likely to work than id-anchors.

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

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 #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

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.

Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann