I tried the following steps on Safari, Windows Vista, r47676: 1. Make the browser window small. Go to http://en.wikipedia.org/wiki/Main_Page. 2. Click on a link on that page. 3. Resize the window to be a lot bigger. 4. Press "Back" RESULT: the wikipedia front page is formatted in the old smaller size, even though the window is bigger now. EXPECTED RESULT: the wikipedia front page should be formatted according to the current window size.
<rdar://problem/5735948> The problem here is when we go back to a cached page, we reuse the cached frame's FrameView which has the old frame rect. This problem does not happen on the Mac because its FrameView is backed by a platform widget (NSView) and it can calculate the layout width/height based on the widget. But the FrameView is not backed by a platform widget on Windows.
Created attachment 38438 [details] Patch
Created attachment 38439 [details] Updated patch - added null check for m_frame->view()
Test case? I believe we can now test b/f cache bugs.
http://trac.webkit.org/browser/trunk/LayoutTests/fast/harness has some examples.
Created attachment 38488 [details] Add layout test Since this test uses some significantly big timeouts, it's not placed under the "fast" folder. Once the pageshow event has been implemented for b/f cache and we use that instead rather than relying on the big timer in this test, we can move this test to under "fast".
Updated the comments about the navigation steps to: // Navigation steps: // 1- loads this page // 2- resizes the window to (300, 300) // 3- loads a data URL that resizes the window to (1000, 1000) and navigates back // 4- loads this page which restores the timer to check the window width to make sure it's > 300
Comment on attachment 38488 [details] Add layout test > Index: LayoutTests/loader/go-back-to-different-window-size.html > =================================================================== > --- LayoutTests/loader/go-back-to-different-window-size.html (revision 0) > +++ LayoutTests/loader/go-back-to-different-window-size.html (revision 0) > @@ -0,0 +1,44 @@ > +<html> > +<script> > + > +// Navigation steps: > +// 1- loads this page > +// 2- resizes the window to (300, 300) > +// 2- loads this page + hash > +// 3- loads a data URL that resizes the window to (1000, 1000) and navigates back > +// 4- loads this page + hash and checks the window width to make sure it's > 300 I think this comment is out of date, and refers to an earlier version of the patch. > + // We don't need to depend on this long timer when pageshow event is implemented for b/f cache (<rdar://problem/6440869>). Could you file a bug to update this test once we've implemented pageshow, and block that bug on the implementing pageshow bug? > + window.setTimeout("verifyWindowSizeAfterNavigateBackToCachedPage()", 1000); As discussed in person, we have a bug with timers when restoring pages from the page cache and this timer fires instantly instead of waiting the full second. We need a bug on this, to at least explore other browsers' behavior and see what we should match. These comments accounted for, r=me
Fix checked in: r47722. Test checked in: r47723. Filed a bug on how restored timers from cached page fires instantly instead of waiting the specified delay first: https://bugs.webkit.org/show_bug.cgi?id=28683 Filed a bug about changing loader/go-back-to-different-window-size.html to use the pageshow event once it's implemented: <rdar://problem/7165517>
Created attachment 38499 [details] Skip test for qt and gtk Skip the test for qt and gtk due to missing DRT ability to override 'standard' preferences
Comment on attachment 38438 [details] Patch Looks like this was landed. Clearing r=?
Yes, the fix was landed. Thanks for clearing the review flag!