When loading a slow page from a URL that points to an #anchor, Safari/WebKit will scroll to the anchor once it's found in the page. I'd like to suggest that some types of user interaction (selecting text, focusing on form controls, maybe scrolling) prior to finding the anchor should cancel the pending repositioning. My assumption is that such input indicates that the user has started reading elsewhere and that it would be impolite to interrupt. I don' know if people in general will see this as a solid usability improvement or just unpredictable behavior, so feel free to disagree. (I further suspect the gain may be too small given the necessary code change, but sometimes pleasing the top 1% is the right thing to do. :-)
This is a duplicate of an existing bug which I can't seem to find.
Was this fixed by r21454? http://trac.webkit.org/projects/webkit/changeset/21454
(In reply to comment #1) > This is a duplicate of an existing bug which I can't seem to find. > Bug 4051? More discussion at bug 3390.
Thanks for the pointers! Bug 4051 doesn't seem directly related to anchors but the underlying problem may be the same. Comment #12 of bug 3390 is spot-on, though the ticket itself started with a different bug. Should we merge tickets anyway? I think it will be difficult to define exactly when to cancel a pending scroll. Selecting text or interacting with a form are both safe bets but merely scrolling is not so obvious. Maybe the user is just impatient and repeatedly hits PgDn or End to see how much content that has loaded so far. On the other hand, convoluted rules involving key sequences or timers aren't necessarily less confusing. (In reply to comment #2) > Was this fixed by r21454? Nope, running r21528 now and still see it. A good test case that I use is www.autoblog.com -- click on any of the "Comment" links on the main page and you've got plenty of time before all ads load and the scroll takes place.
Related fix: http://trac.webkit.org/projects/webkit/changeset/24550
*** Bug 4051 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Nope, running r21528 now and still see it. A good test case that I use is > www.autoblog.com -- click on any of the "Comment" links on the main page and > you've got plenty of time before all ads load and the scroll takes place. > I'm testing and testing and I don't see described behavior. The page loads almost instantly, so maybe it's too little time to observe it. Is it still visible to you?
> I'm testing and testing and I don't see described behavior. The page loads > almost instantly, so maybe it's too little time to observe it. Is it still > visible to you? > No answer since February 2008. I think it's time to close this bug report.