RESOLVED INVALID 13770
Cancel pending scroll to #anchor if user interacts with the page 
https://bugs.webkit.org/show_bug.cgi?id=13770
Summary Cancel pending scroll to #anchor if user interacts with the page
Jonas Walldén
Reported 2007-05-18 03:55:23 PDT
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. :-)
Attachments
Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2007-05-19 00:42:19 PDT
This is a duplicate of an existing bug which I can't seem to find.
David Kilzer (:ddkilzer)
Comment 2 2007-05-19 03:35:10 PDT
Was this fixed by r21454? http://trac.webkit.org/projects/webkit/changeset/21454
mitz
Comment 3 2007-05-19 12:01:56 PDT
(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.
Jonas Walldén
Comment 4 2007-05-19 12:48:50 PDT
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.
David Kilzer (:ddkilzer)
Comment 5 2007-07-23 22:21:18 PDT
Related fix: http://trac.webkit.org/projects/webkit/changeset/24550
David Kilzer (:ddkilzer)
Comment 6 2007-07-23 22:25:58 PDT
*** Bug 4051 has been marked as a duplicate of this bug. ***
Robert Blaut
Comment 7 2008-02-24 02:48:31 PST
(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?
Robert Blaut
Comment 8 2008-12-28 11:57:13 PST
> 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.
Note You need to log in before you can comment on or make changes to this bug.