Last Comment Bug 644 - Checking on named anchors (#foo) in page forces reload
: Checking on named anchors (#foo) in page forces reload
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows 95
P1 major (vote)
: M3
Assigned To: troy
: rubydoo123
: Jet Villegas (:jet)
: 1560 2579 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 1998-08-08 07:00 PDT by Angus Davis
Modified: 1999-04-21 11:23 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Angus Davis 1998-08-08 07:00:00 PDT
Let's say you're on a page, such as:

And you click on the "What's New" link, whose URL is:

It should just scroll you down to the location of that anchor (#new), but
instead, it reloads the page before scrolling down to the named anchor.
Comment 1 User image James Everingham 1998-09-11 01:23:59 PDT
Troy, who gets this?
Comment 2 User image Angus Davis 1998-10-22 17:33:59 PDT
Comment 3 User image troy 1998-10-22 17:52:59 PDT
Rick, I don't have much to do with link processing so I'm giving it to you
Comment 4 User image joki (gone) 1998-11-24 13:19:59 PST
*** Bug 1560 has been marked as a duplicate of this bug. ***
Comment 5 User image David Baron :dbaron: ⌚️UTC-8 1998-12-20 08:40:59 PST
In addition to forcing a reload, anchor links now don't move to the anchor
after the reload either.  See, for example,

This should work for both A NAME="..." and ID="..." anchors.
Comment 6 User image don 1999-01-05 15:26:59 PST
Re-assigned to

Gagan, is this a netlib bug?  Who should get this?
Comment 7 User image Gagan 1999-01-14 10:24:59 PST
Not netlib for sure. Layout...?
Comment 8 User image Angus Davis 1999-01-14 12:48:59 PST
Adding Rick Potts to the cc: list. Maybe the docloader handles this; I dunno.
Comment 9 User image troy 1999-01-14 20:58:59 PST
Here's what happens. The nsHTMLAnchorElement code ends up calling the link
handler and having it handle the link click. The link handler is the Web shell
and it doesn't check for the same URL and a fragment identifier, it just loads
the same document. We don't even seem to respect the fragment identifier so we
just go to the top of the document

I don't know how this used to work. Kipp probably knows. I don't know why things
have changed, but since the Web shell is the link handler I'm assigning it to
Rick Potts

Let's try and be adults about this and stop treating this bug like a hot potato
Comment 10 User image Hixie (not reading bugmail) 1999-01-23 17:13:59 PST
*** Bug 2579 has been marked as a duplicate of this bug. ***
Comment 11 User image Hixie (not reading bugmail) 1999-01-23 17:16:59 PST
Guys, any chance this could be fixed soon? It's making QA a right pain
in the neck.

Pumping up the priority.
Comment 13 User image leger 1999-02-03 08:03:59 PST
Setting all current Open Critical and Major to M3
Comment 14 User image troy 1999-02-11 21:52:59 PST
Fixed so we don't reload the document
Comment 15 User image David Baron :dbaron: ⌚️UTC-8 1999-02-16 10:37:59 PST
Verified fixed.
Comment 16 User image David Baron :dbaron: ⌚️UTC-8 1999-02-16 10:39:59 PST
Whoops... I take that back.  The document still reloads when you hit the back
button after going to a named anchor, when it is moving back to the original
(non-anchor) position.  Also, the URL doesn't change when I go to a named
Comment 17 User image troy 1999-02-16 10:48:59 PST
The problems you mention when you reopened the bug are different than the
originally described problem, so I think the right thing to do is to leave this
bug fixed and create additional bugs for the new problems
Comment 18 User image David Baron :dbaron: ⌚️UTC-8 1999-02-16 10:58:59 PST
OK...filed bug 3152 and re-resolved this one.
Comment 19 User image troy 1999-02-16 11:01:59 PST
Comment 20 User image rubydoo123 1999-02-16 11:13:59 PST
I can't verify this one, on the 2/10 build the name anchor does not work. More
recent builds don't display the content correctly. Will check in a couple of
Comment 21 User image rubydoo123 1999-02-23 10:55:59 PST
name attributes now work on 2/22/99 build, setting bug as  verified

Note You need to log in before you can comment on or make changes to this bug.