Bug 51899 - Scroll history takes precedence over window.scrollTo
Summary: Scroll history takes precedence over window.scrollTo
Status: RESOLVED DUPLICATE of bug 147782
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 147782
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-04 14:41 PST by Yohann Richard
Modified: 2016-01-07 13:32 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yohann Richard 2011-01-04 14:41:39 PST
Facebook needs to be able to set the scroll location onload of a page.

Unfortunately, webkit restores the scroll location for a reloaded page even if it was previously set by a javascript call.

It seems that this restore happens after the onload event is fired, making it hard to override without a setTimeout deferring a scrollTo after a totally arbitrary interval.

Acceptable solutions would be either not to restore the position if it was already set by the JS code, either to restore the position before the onload event is triggered.

To reproduce on webkit nightly, Safari or Chrome, use the following code, load the page, it should scroll to 500px. Scroll to the top, click the refresh button. 
The logs will show that an onscroll event was first triggered when the page scrolled to 500, then a second one was triggered when the browser restored the position to 0.


<html>
  <body>
    <script>
      window.onload=function() {
        window.scrollTo(0, 500);
      };
   
      document.onscroll=function() {
        console.log('scroll', document.body.scrollTop); 
      };
    </script>
    <div style="height:10000px">test</div>
  </body>
</html>
Comment 1 Rick Byers 2015-08-07 08:13:37 PDT
I believe bug 147782 would address this issue.
Comment 2 Rick Byers 2016-01-07 13:32:55 PST

*** This bug has been marked as a duplicate of bug 147782 ***