Bug 3390 – Destination anchors are sometimes ignored

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Étienne Després]

http://www.pochour.com/test.html#test

This link should scroll down to the <p id="test"> element. Works in Firefox 1.0.3, OmniWeb 5.0.1, iCab 3; 
fails in Safari 2.0 (412, 10.4.1).

Removing line 5 (<link ... />) seems to fix it.

[Étienne Després]

I should add that it *sometimes* seem to work properly. If it does, try downloading the HTML file locally, 
loading that file in Safari and manually adding "#test" after the URL. This consistently fails here.

[Chris Petersen]

I can confirm this on both TOT and Safari 2 (v412). This link will fail to scroll to the bottom of page when 
it's processed for the first time.  If I click on the link (http://www.pochour.com/test.html#test) , press the 
back arrow to return back, then click the link again, the page will be scrolled to the bottom after this link 
is processed again.

[Stuart Morgan]

*** Bug 5366 has been marked as a duplicate of this bug. ***

[Chris Blackstone]

I think this has something to do with alternate style sheets.

I set up http://www.arlington.k12.va.us/webmaster/test_anchor/

Following the links in the No CSS Links Page section works every time
There is less success with the links under the last 2 lists. When they come up unstyled, they work 
correctly, but if you scroll to the top of the destination page and click on one of the "A"s to select a style 
sheet, often the destinations then don't work.

[Mark Rowe (bdash)]

The scrolling to anchor is handled in FrameLoader::gotoAnchor.  In the failing case the node referenced by the anchor does not yet have a renderer when the HTML parsing finishes as the document still has stylesheets loading.  As there is no renderer it is not possible to scroll the enclosing layer to the correct position.  It seems as though gotoLayer needs to be called again once the pending stylesheets have loaded so that the nodes renderer will definitely be around.

[Mark Rowe (bdash)]

Created attachment 13627 [details]
Patch

[Darin Adler]

Comment on attachment 13627 [details]
Patch

But what if the user has been interacting with the page and has done some scrolling of his own?

[David Kilzer (:ddkilzer)]

I think Bug 12420 is a duplicate of this bug.

[David Kilzer (:ddkilzer)]

Reassigning to webkit-unassigned for more visibility.

[David Kilzer (:ddkilzer)]

*** Bug 12420 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> *** Bug 12420 has been marked as a duplicate of this bug. ***

<rdar://problem/5045723>

[Mark Rowe (bdash)]

(In reply to comment #7)
> (From update of attachment 13627 [details] [edit])
> But what if the user has been interacting with the page and has done some
> scrolling of his own?
> 

The behaviour is the same as with a very large page with no external resources that has anchors near the bottom was loaded.  In that situation the user is able to interact with the page until the parsing completes and then we scroll to the anchor.  It's tricky to reproduce this at work with such a quick network connection, but you can see this behaviour by visiting <http://www.whatwg.org/specs/web-forms/current-work/?#acknowledgements>.  As soon as the scrollbar appears, click in the trough to page down.  When the document finishes loading you will be taken from your view of the start of the Table of Contents down to the Acknowledgement section.

(In reply to comment #12)
> The behaviour is the same as with a very large page with no external resources
> that has anchors near the bottom was loaded.

Bug 4051?

[Mark Rowe (bdash)]

Yes, that would be it.

[Mark Rowe (bdash)]

Actually, on closer inspection that is different.  Restoring the view position and jumping to an anchor are handled separately.

[David Kilzer (:ddkilzer)]

(In reply to comment #12)
> The behaviour is the same as with a very large page with no external resources
> that has anchors near the bottom was loaded.  In that situation the user is
> able to interact with the page until the parsing completes and then we scroll
> to the anchor.  It's tricky to reproduce this at work with such a quick network
> connection, but you can see this behaviour by visiting
> <http://www.whatwg.org/specs/web-forms/current-work/?#acknowledgements>.  As
> soon as the scrollbar appears, click in the trough to page down.  When the
> document finishes loading you will be taken from your view of the start of the
> Table of Contents down to the Acknowledgement section.

Are Firefox, MSIE or Opera nice enough not to re-scroll to the anchor after the user has started scrolling themselves?

In my limited amount of testing, both Firefox 2.0.0.2 and Opera 9.10 still attempt to scroll to the anchor after the user has scrolled while the page was loading.

[Mark Rowe (bdash)]

Camino was the only other browser I tested in, and it also scrolls to the anchor even if the user has scrolled before the anchor had loaded.

[Antti Koivisto]

Comment on attachment 13627 [details]
Patch

With this patch the view may scroll to correct position when parsing completes, user starts scrolling around and then the view will suddenly jump back to anchor on load complete. I don't think this is a good behavior. Perhaps it would make sense to check if you have scrolled to a particular position already. That would eliminate many cases of unnecessary double scrolling.

[Antti Koivisto]

Or maybe it shouldn't jump at all if it has already done one jump and user has scrolled the view? Or in that case check the difference between new and old target position and only scroll if it is big?

[Antti Koivisto]

Outside scope of this bug, but...

Current approach to anchor scrolling is not optimal in general. Jumping should not be tied to parse complete/load complete. On a slow loading document or one with blocking javascript load at the end the jump maybe happen long after the target position has appeared on the screen, giving perception of slowness.

Perhaps the jump could be done earlier, at first repaint after the renderer for target anchor has been created and placed in layout (and document is sufficiently tall to put it to top of the page).

[Mark Rowe (bdash)]

Antti, that approach would lead to similar issues if you had, for example, images higher up the page with a large intrinsic heigh and no explicit height set.  We would scroll to the anchor when it is first painted, then the images would load, another layout would take place and the anchor could be shifted a considerable distance from where we initially scrolled to.

[David Kilzer (:ddkilzer)]

(In reply to comment #21)
> Antti, that approach would lead to similar issues if you had, for example,
> images higher up the page with a large intrinsic heigh and no explicit height
> set.  We would scroll to the anchor when it is first painted, then the images
> would load, another layout would take place and the anchor could be shifted a
> considerable distance from where we initially scrolled to.

See Bug 13311.

[Mark Rowe (bdash)]

To clarify on Dave's comment, bug 13311 is an example of a situation in which images loading after the scroll already causes it to appear as though we have scrolled to the wrong place.  It's horrible.

[David Kilzer (:ddkilzer)]

Should be fixed by r24550:

http://trac.webkit.org/projects/webkit/changeset/24550

[David Kilzer (:ddkilzer)]

*** Bug 9549 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

*** Bug 14001 has been marked as a duplicate of this bug. ***

[Adam Barth]

This bug claims to have been fixed in Comment #24.