Bug 33931
| Summary: | pushstate() from within a popstate handler might lead to improper scroll/view state being incorrect later | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brady Eidson <beidson> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | fishd, justin.lebar+bug |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Brady Eidson
pushstate() from within a popstate handler might lead to improper scroll/view state being incorrect later
See the test case in https://bugs.webkit.org/show_bug.cgi?id=33830 for reference.
Since the popstate event - fired from within FrameLoader::loadInSameDocument() called from FrameLoader::navigateWithinDocument() - can effectively change the current history item, the later call to history()->restoreScrollPositionAndViewState() will be operating on the wrong "current history item" from the perspective of the load.
There's a lot of complexity here in getting this precisely right, especially since popstate events might nest and we'd probably only want to restore the scroll/view state from the most recently popped item.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Darin Fisher (:fishd, Google)
We should be very careful here since history()->restoreScrollPositionAndViewState() may lead to the scroll event being dispatched. Can the app do other things within the popstate event that could cause the scroll event to be confusing to the app? (This re-entrancy stuff gives me a headache!)
Justin Lebar
Forgot to include a link above:
[2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#event-definitions
Justin Lebar
Oops, wrong bug. Sorry!