Checking on named anchors (#foo) in page forces reload

VERIFIED FIXED in M3

Status

()

Core
Layout
P1
major
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Angus Davis, Assigned: troy)

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
Let's say you're on a page, such as:
http://warp/java/oji/index.html

And you click on the "What's New" link, whose URL is:
http://warp/java/oji/index.html#new

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.

Updated

19 years ago
Status: NEW → ASSIGNED
Component: Unknown → Content Model

Comment 1

19 years ago
Troy, who gets this?
(Reporter)

Updated

19 years ago
Assignee: jevering → troy
Status: ASSIGNED → NEW
(Reporter)

Comment 2

19 years ago
troy?
(Assignee)

Updated

19 years ago
Assignee: troy → rpotts
(Assignee)

Comment 3

19 years ago
Rick, I don't have much to do with link processing so I'm giving it to you

Comment 4

19 years ago
*** Bug 1560 has been marked as a duplicate of this bug. ***
In addition to forcing a reload, anchor links now don't move to the anchor
after the reload either.  See, for example,
http://www.fas.harvard.edu/~dbaron/links/Internet.html

This should work for both A NAME="..." and ID="..." anchors.

Updated

19 years ago
Assignee: rpotts → gagan

Comment 6

19 years ago
Re-assigned to gagan@netscape.com.

Gagan, is this a netlib bug?  Who should get this?

Updated

19 years ago
Assignee: gagan → troy
Component: Content Model → Layout

Comment 7

19 years ago
Not netlib for sure. Layout...?
(Reporter)

Comment 8

19 years ago
Adding Rick Potts to the cc: list. Maybe the docloader handles this; I dunno.
(Assignee)

Updated

19 years ago
Assignee: troy → rpotts
(Assignee)

Comment 9

19 years ago
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
*** Bug 2579 has been marked as a duplicate of this bug. ***
Priority: P2 → P1
Guys, any chance this could be fixed soon? It's making QA a right pain
in the neck.

Pumping up the priority.
Severity: normal → major
Extra test pages for whoever is implementing this:
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/anchor1.html
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/anchor2.html
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/anchor3.html

Comment 13

19 years ago
Setting all current Open Critical and Major to M3
(Assignee)

Updated

19 years ago
Assignee: rpotts → troy
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

19 years ago
Fixed so we don't reload the document
Status: RESOLVED → VERIFIED
Verified fixed.
Status: VERIFIED → REOPENED
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
anchor.
(Assignee)

Comment 17

19 years ago
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
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
OK...filed bug 3152 and re-resolved this one.
(Assignee)

Comment 19

19 years ago
Thanks

Updated

19 years ago
QA Contact: 3849

Comment 20

19 years ago
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
days

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 21

19 years ago
name attributes now work on 2/22/99 build, setting bug as  verified
You need to log in before you can comment on or make changes to this bug.