Loading the above URL should scroll the page to the named anchor titled "jamesbond". The code in the content sink that scrolls to an anchor once the page is done loading needs to be fixed so that it uses the presshell's GotoAnchor() method. Thanks to Johnny for identifying this problem and suggesting a fix...

Marking nsbeta3 and setting target milestone to M18...

Marking nsbeta3+. Trivial fix. Affects a large number of link traversals.

nsDocShell::ScrollIfAnchor takes care of parsing the URI for the anchor and calls GotoAnchor() but it only works for reloads or anchors in the same document because it compares the old URI with the new one. This may be a bit more complicated to do when loading a new document because in the case of a large document (like the W3C's CSS specs), you want to navigate to the anchor after that part of the document is loaded but before the entire document is finished loading. Also, what should happen when the user manually scrolls the page before the part of the document that contains the anchor is loaded? Should manual scrolling override the navigation to the anchor or should it jump to it anyway?

Unfortunately, I am not going to have the time to fix this. Marking nsbeta3- and futuring.

This bug has been marked nsbeta3- because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration, but do not clear the nsbeta3- nomination.

Might this be related to bug 55244? That one seems to have a fix being developed...

*If* behavior is identical when typical a URL with an anchor into the URL bar (bug 45338) and when clicking a link in the page (bug 56285), then bug 45338 and bug 56285 may be DUPs. Suggest that Nisheeth fix bug 45338 or Adam fix bug 56285 and then see whether both bugs disappear, rather than working on separate fixes independently.

I'm running nightly 2000102420 on Win98se and don't see this bug anymore. I opened the test URL by pasting into the address box in the navigation toolbar as well as using the File -> Open Web Location... menu option. Was this fixed when bug 56285 was fixed?

I'm seeing slightly different behavior now. Named anchors are working, but aren't scrolling to the exact line of the anchor. For example, when bringing up the security advisor, various links will bring up a help window, and scroll to a particular anchor. Consistently the scroll position is off by one line, so the line is just out of view. Go to www.mozilla.org, and click on the lock icon. The security advisor will show a window that says "The web site www.mozilla.org does not support authentication for the page you are viewing." The word authentication is a hyperlink that brings up a help window that has an incorrect scroll position.

This is a dupe, I fixed it a while ago for XML, and Adam Lock fixed it for HTML. However, there is still the bug of not scrolling to an anchor *immediately* when we have loaded that anchor - right now we scroll after the complete document has loaded. But that is a separate bug somebody might want to file... *** This bug has been marked as a duplicate of 57437 ***