45338 - Scrolling to an anchor on page load does not work

Status: RESOLVED DUPLICATE of bug 57437

(Core :: Layout, defect, P3)

Description

[Nisheeth Ranjan]

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

Comment 1

[Nisheeth Ranjan]

Marking nsbeta3 and setting target milestone to M18...

Comment 2

[Nisheeth Ranjan]

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

Comment 3

[Peter Lubczynski]

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?

Comment 4

[Nisheeth Ranjan]

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

Comment 5

[Nisheeth Ranjan]

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.

Comment 6

[djk]

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

Comment 7

[ekrock's old account (dead)]

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

Comment 8

[djk]

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?

Comment 9

[Patrick C. Beard]

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.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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