[Webkit-unassigned] [Bug 41074] New: When restoring scroll position from history we should inflate the content size so that the race condition is eliminated
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Jun 23 09:30:55 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=41074
Summary: When restoring scroll position from history we should
inflate the content size so that the race condition is
eliminated
Product: WebKit
Version: 528+ (Nightly build)
Platform: PC
OS/Version: Mac OS X 10.5
Status: NEW
Severity: Normal
Priority: P2
Component: History
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: treat at kde.org
Currently, we see this comment in HistoryController.cpp:
/*
There is a race condition between the layout and load completion that affects restoring the scroll position.
We try to restore the scroll position at both the first layout and upon load completion.
1) If first layout happens before the load completes, we want to restore the scroll position then so that the
first time we draw the page is already scrolled to the right place, instead of starting at the top and later
jumping down. It is possible that the old scroll position is past the part of the doc laid out so far, in
which case the restore silent fails and we will fix it in when we try to restore on doc completion.
2) If the layout happens after the load completes, the attempt to restore at load completion time silently
fails. We then successfully restore it when the layout happens.
*/
I propose that we add contentsSize to the HistoryItem and restore that before restoring the scroll position to eliminate this race condition. It won't work for reload types all the time, but will for the majority of cases where the content size will not differ too drastically (my intuition tells me ;)
Patch forthcoming...
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list