Title: [209932] trunk
Revision
209932
Author
akl...@apple.com
Date
2016-12-16 12:44:01 -0800 (Fri, 16 Dec 2016)

Log Message

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:

Modified Paths

Diff

Modified: trunk/LayoutTests/ChangeLog (209931 => 209932)


--- trunk/LayoutTests/ChangeLog	2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/ChangeLog	2016-12-16 20:44:01 UTC (rev 209932)
@@ -1,3 +1,20 @@
+2016-12-16  Andreas Kling  <akl...@apple.com>
+
+        Subframes going into page cache don't need to resetScrollbars().
+        <https://webkit.org/b/163750>
+        <rdar://problem/29273020>
+
+        Reviewed by Antti Koivisto.
+
+        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:
+
 2016-12-16  Wenson Hsieh  <wenson_hs...@apple.com>
 
         Visual viewports: carets and selection UI are incorrectly positioned when editing fixed elements

Modified: trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt (209931 => 209932)


--- trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt	2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt	2016-12-16 20:44:01 UTC (rev 209932)
@@ -23,7 +23,7 @@
               (children 1
                 (GraphicsLayer
                   (anchor 0.00 0.00)
-                  (bounds 285.00 150.00)
+                  (bounds 285.00 135.00)
                   (children 1
                     (GraphicsLayer
                       (children 1
@@ -73,7 +73,7 @@
                   (children 1
                     (GraphicsLayer
                       (anchor 0.00 0.00)
-                      (bounds 285.00 150.00)
+                      (bounds 285.00 135.00)
                       (children 1
                         (GraphicsLayer
                           (children 1

Modified: trunk/LayoutTests/platform/mac-wk1/TestExpectations (209931 => 209932)


--- trunk/LayoutTests/platform/mac-wk1/TestExpectations	2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/platform/mac-wk1/TestExpectations	2016-12-16 20:44:01 UTC (rev 209932)
@@ -285,8 +285,6 @@
 webkit.org/b/163361 imported/w3c/web-platform-tests/html/webappapis/animation-frames/callback-invoked.html [ Pass Failure ]
 webkit.org/b/163361 imported/w3c/web-platform-tests/html/webappapis/animation-frames/callback-multicalls.html [ Pass Failure ]
 
-webkit.org/b/163750 compositing/iframes/page-cache-layer-tree.html [ Pass Failure ]
-
 webkit.org/b/164491 [ Yosemite ElCapitan ] fast/visual-viewport/rtl-zoomed-rects.html [ Failure ]
 
 webkit.org/b/164933 http/tests/misc/link-rel-icon-beforeload.html [ Failure ]

Modified: trunk/Source/WebCore/ChangeLog (209931 => 209932)


--- trunk/Source/WebCore/ChangeLog	2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/Source/WebCore/ChangeLog	2016-12-16 20:44:01 UTC (rev 209932)
@@ -1,3 +1,25 @@
+2016-12-16  Andreas Kling  <akl...@apple.com>
+
+        Subframes going into page cache don't need to resetScrollbars().
+        <https://webkit.org/b/163750>
+        <rdar://problem/29273020>
+
+        Reviewed by Antti Koivisto.
+
+        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):
+
 2016-12-16  Wenson Hsieh  <wenson_hs...@apple.com>
 
         Visual viewports: carets and selection UI are incorrectly positioned when editing fixed elements

Modified: trunk/Source/WebCore/dom/Document.cpp (209931 => 209932)


--- trunk/Source/WebCore/dom/Document.cpp	2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/Source/WebCore/dom/Document.cpp	2016-12-16 20:44:01 UTC (rev 209932)
@@ -4540,8 +4540,7 @@
                 v->resetScrollbarsAndClearContentsSize();
                 if (ScrollingCoordinator* scrollingCoordinator = page->scrollingCoordinator())
                     scrollingCoordinator->clearStateTree();
-            } else
-                v->resetScrollbars();
+            }
         }
 
 #if ENABLE(POINTER_LOCK)
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to