Subframes going into page cache don't need to resetScrollbars().
authorakling@apple.com <akling@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 16 Dec 2016 20:44:01 +0000 (20:44 +0000)
committerakling@apple.com <akling@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 16 Dec 2016 20:44:01 +0000 (20:44 +0000)
commit280e079e6bcd189d7d49fdd9cc39fe6019742746
tree5726037e1388db7c1d9adaad00044d6d887fbfe8
parent63089ee2c1c77558ad06563366b3f41f9820d78c
Subframes going into page cache don't need to resetScrollbars().
<https://webkit.org/b/163750>
<rdar://problem/29273020>

Reviewed by Antti Koivisto.

Source/WebCore:

The main frame is the only frame that switches its FrameView when using the page cache,
subframes just suspend their DOM and wait around to be either killed or restored.

Thus there is no reason for subframes to reset their FrameView's scrollbars when going
into page cache, since nothing affects them while cached, and their layout should end up
identical when restoring.

This was causing some flakiness with subframe scrollbars jumping between different sizes
in when restoring from page cache in macOS/WK1. This change makes the behavior consistent
in both WK1 and WK2, and removes the flakiness.

* dom/Document.cpp:
(WebCore::Document::setPageCacheState):

LayoutTests:

Unskip compositing/iframes/page-cache-layer-tree.html on mac-wk1 and fix up the
result now that WK2 behaves correctly as well.

Both DRT and WTR run with scrollbars in "always on" mode, so the correct dimensions
for the 300x150 iframe layers here are 285x135.

* compositing/iframes/page-cache-layer-tree-expected.txt:
* platform/mac-wk1/TestExpectations:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@209932 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt
LayoutTests/platform/mac-wk1/TestExpectations
Source/WebCore/ChangeLog
Source/WebCore/dom/Document.cpp