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.
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.
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.
*** Bug 5366 has been marked as a duplicate of this bug. ***
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.
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.
Created attachment 13627 [details] Patch
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?
I think Bug 12420 is a duplicate of this bug.
Reassigning to webkit-unassigned for more visibility.
*** Bug 12420 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 12420 has been marked as a duplicate of this bug. *** <rdar://problem/5045723>
(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?
Yes, that would be it.
Actually, on closer inspection that is different. Restoring the view position and jumping to an anchor are handled separately.
(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.
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.
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.
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?
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).
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.
(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.
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.
Should be fixed by r24550: http://trac.webkit.org/projects/webkit/changeset/24550
*** Bug 9549 has been marked as a duplicate of this bug. ***
*** Bug 14001 has been marked as a duplicate of this bug. ***
This bug claims to have been fixed in Comment #24.