Regression from http://trac.webkit.org/changeset/82185/trunk/Source/WebCore * STEPS TO REPRODUCE 1. Navigate to <http://en.wikipedia.org/wiki/MathML> 2. Scroll down 3. In the same tab, navigate to >about:blank> 4. Choose History > Back * RESULTS The Wikipedia page is scrolled to the top. <rdar://problem/9226652>
Created attachment 90106 [details] Patch
Comment on attachment 90106 [details] Patch r=me
Comment on attachment 90106 [details] Patch Why no tests? :) It should be very easy to be tested, unless I am missing something ...
(In reply to comment #3) > (From update of attachment 90106 [details]) > Why no tests? :) > > It should be very easy to be tested, unless I am missing something ... You're right, Antonio! I wrote a test that I will commit with the change.
> > > > It should be very easy to be tested, unless I am missing something ... > > You're right, Antonio! I wrote a test that I will commit with the change. Perfect
Committed fix and test with revision 84296.
http://trac.webkit.org/changeset/84296 might have broken Qt Linux Release
(In reply to comment #7) > http://trac.webkit.org/changeset/84296 might have broken Qt Linux Release new bug for it: https://bugs.webkit.org/show_bug.cgi?id=58977
(In reply to comment #7) > http://trac.webkit.org/changeset/84296 might have broken Qt Linux Release Probably FrameView::resetScrollbarsAndClearContentsSize() is never called in some cases like when it loads an unreachable URL, then the cached scroll position is always (0, 0) and the real scroll position is lost. I don't think the solution is right. HistoryController and ScrollView shouldn't think that much. Who resets contents size to (0, 0) should be responsible to restore the scroll position when contents size changes back.
(In reply to comment #9) > (In reply to comment #7) > > http://trac.webkit.org/changeset/84296 might have broken Qt Linux Release > > Probably FrameView::resetScrollbarsAndClearContentsSize() is never called in some cases like when it loads an unreachable URL, then the cached scroll position is always (0, 0) and the real scroll position is lost. I don't think the solution is right. HistoryController and ScrollView shouldn't think that much. Who resets contents size to (0, 0) should be responsible to restore the scroll position when contents size changes back. Beth, could you reply to Yong's comment, please? It broke something important for us.
Hi Yong and Antontio, I discovered that this caused a regression in Safari as well: though my patch made pages in the page cache properly restore scroll position on reload, it regressed pages that do not go into the page cache. This pages no longer restore scroll position. I have a fix and a layout test that I will post shortly. Hopefully it fixes the QT test as well.
Created attachment 90672 [details] Patch that restores scroll position for cached and non-cached pages
Comment on attachment 90672 [details] Patch that restores scroll position for cached and non-cached pages View in context: https://bugs.webkit.org/attachment.cgi?id=90672&action=review > Source/WebCore/ChangeLog:12 > + *not* in the page cache. This patch fixed both cached and non-cached pages by “fixed” or “fixes”?
Thanks Dan! Committed fix with revision 84604.
It looks like this still happens for in-page navigations. I filed bug 59877 for this.
*** Bug 59877 has been marked as a duplicate of this bug. ***