Closed
Bug 644
Opened 26 years ago
Closed 26 years ago
Checking on named anchors (#foo) in page forces reload
Categories
(Core :: Layout, defect, P1)
Tracking
()
VERIFIED
FIXED
M3
People
(Reporter: angus, Assigned: troy)
References
()
Details
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•26 years ago
|
Status: NEW → ASSIGNED
Component: Unknown → Content Model
Comment 1•26 years ago
|
||
Troy, who gets this?
Reporter | ||
Updated•26 years ago
|
Assignee: jevering → troy
Status: ASSIGNED → NEW
Reporter | ||
Comment 2•26 years ago
|
||
troy?
Rick, I don't have much to do with link processing so I'm giving it to you
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.
Re-assigned to gagan@netscape.com. Gagan, is this a netlib bug? Who should get this?
Reporter | ||
Comment 8•26 years ago
|
||
Adding Rick Potts to the cc: list. Maybe the docloader handles this; I dunno.
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•26 years ago
|
||
*** Bug 2579 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Priority: P2 → P1
Comment 11•26 years ago
|
||
Guys, any chance this could be fixed soon? It's making QA a right pain in the neck. Pumping up the priority.
Updated•26 years ago
|
Severity: normal → major
Comment 12•26 years ago
|
||
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•26 years ago
|
||
Setting all current Open Critical and Major to M3
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•26 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•26 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
Closed: 26 years ago → 26 years ago
OK...filed bug 3152 and re-resolved this one.
Assignee | ||
Comment 19•26 years ago
|
||
Thanks
Updated•26 years ago
|
QA Contact: 3849
Comment 20•26 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•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 21•26 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.
Description
•