Bug 3390 - Destination anchors are sometimes ignored
Summary: Destination anchors are sometimes ignored
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 412
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.pochour.com/test.html#test
Keywords: InRadar
: 5366 9549 12420 14001 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-09 13:41 PDT by Étienne Després
Modified: 2010-09-15 01:00 PDT (History)
10 users (show)

See Also:


Attachments
Patch (8.38 KB, patch)
2007-03-13 23:01 PDT, Mark Rowe (bdash)
koivisto: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Étienne Després 2005-06-09 13:41:05 PDT
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.
Comment 1 Étienne Després 2005-06-09 13:48:46 PDT
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.
Comment 2 Chris Petersen 2005-06-09 18:04:44 PDT
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.
Comment 3 Stuart Morgan 2005-10-14 08:13:43 PDT
*** Bug 5366 has been marked as a duplicate of this bug. ***
Comment 4 Chris Blackstone 2005-10-14 09:57:04 PDT
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.
Comment 5 Mark Rowe (bdash) 2007-03-13 02:49:19 PDT
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.
Comment 6 Mark Rowe (bdash) 2007-03-13 23:01:43 PDT
Created attachment 13627 [details]
Patch
Comment 7 Darin Adler 2007-03-14 07:57:14 PDT
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?
Comment 8 David Kilzer (:ddkilzer) 2007-03-14 10:57:53 PDT
I think Bug 12420 is a duplicate of this bug.

Comment 9 David Kilzer (:ddkilzer) 2007-03-14 10:58:23 PDT
Reassigning to webkit-unassigned for more visibility.

Comment 10 David Kilzer (:ddkilzer) 2007-03-14 11:00:54 PDT
*** Bug 12420 has been marked as a duplicate of this bug. ***
Comment 11 David Kilzer (:ddkilzer) 2007-03-14 11:01:56 PDT
(In reply to comment #10)
> *** Bug 12420 has been marked as a duplicate of this bug. ***

<rdar://problem/5045723>
Comment 12 Mark Rowe (bdash) 2007-03-14 22:07:08 PDT
(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.
Comment 13 mitz 2007-03-14 23:52:29 PDT
(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?
Comment 14 Mark Rowe (bdash) 2007-03-15 00:09:35 PDT
Yes, that would be it.
Comment 15 Mark Rowe (bdash) 2007-03-15 00:10:34 PDT
Actually, on closer inspection that is different.  Restoring the view position and jumping to an anchor are handled separately.
Comment 16 David Kilzer (:ddkilzer) 2007-03-15 04:28:27 PDT
(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.
Comment 17 Mark Rowe (bdash) 2007-03-15 04:52:58 PDT
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 18 Antti Koivisto 2007-03-15 05:40:07 PDT
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.
Comment 19 Antti Koivisto 2007-03-15 06:01:45 PDT
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?
Comment 20 Antti Koivisto 2007-03-15 11:07:24 PDT
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).
Comment 21 Mark Rowe (bdash) 2007-03-15 18:41:25 PDT
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.
Comment 22 David Kilzer (:ddkilzer) 2007-04-09 21:00:45 PDT
(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.

Comment 23 Mark Rowe (bdash) 2007-04-09 21:02:18 PDT
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.
Comment 24 David Kilzer (:ddkilzer) 2007-07-23 22:30:13 PDT
Should be fixed by r24550:

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

Comment 25 David Kilzer (:ddkilzer) 2007-07-23 22:32:50 PDT
*** Bug 9549 has been marked as a duplicate of this bug. ***
Comment 26 David Kilzer (:ddkilzer) 2007-07-23 22:33:19 PDT
*** Bug 14001 has been marked as a duplicate of this bug. ***
Comment 27 Adam Barth 2010-09-15 01:00:14 PDT
This bug claims to have been fixed in Comment #24.