Title: [168078] trunk
Revision
168078
Author
simon.fra...@apple.com
Date
2014-04-30 19:15:17 -0700 (Wed, 30 Apr 2014)

Log Message

[iOS WK2] Some accerated overflow-scroll doesn't scroll correctly
https://bugs.webkit.org/show_bug.cgi?id=132375

Reviewed by Tim Horton.

Source/WebCore:
We set the size of the scrolling layer (which becomes the bounds of
the UIScrollView) to a non-pixel-snapped padding box size, but the
size of the contents layer is an integral-snapped scroll size.
This would result in a fractional difference between the two, which
makes us thing that the element is scrollable when it really is not.

Fix by setting the size of the scroll layer to pixel snapped client size,
which is what we also use for scrollability computation.

Added some FIXMEs in code that requires pixel snapping.

Also use #if PLATFORM(IOS)/#else to bracket some code that never runs on iOS
but tries to do something similar to iOS-only code.

* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGraphicsLayerGeometry):

LayoutTests:
New test that dumps compositing layers on iOS so we can see the sizes of the
scroll layers that get created.

* compositing/overflow/subpixel-overflow-expected.txt: Added.
* compositing/overflow/subpixel-overflow.html: Added.
* platform/ios-sim/compositing/overflow/subpixel-overflow-expected.txt: Added.
* platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt:
This is a progression; the old code failed to take the scrollbar width into
account, and the new code does.

Modified Paths

Added Paths

Diff

Modified: trunk/LayoutTests/ChangeLog (168077 => 168078)


--- trunk/LayoutTests/ChangeLog	2014-05-01 02:15:15 UTC (rev 168077)
+++ trunk/LayoutTests/ChangeLog	2014-05-01 02:15:17 UTC (rev 168078)
@@ -1,5 +1,23 @@
 2014-04-30  Simon Fraser  <simon.fra...@apple.com>
 
+        [iOS WK2] Some accerated overflow-scroll doesn't scroll correctly
+        https://bugs.webkit.org/show_bug.cgi?id=132375
+
+        Reviewed by Tim Horton.
+        
+        New test that dumps compositing layers on iOS so we can see the sizes of the
+        scroll layers that get created.
+        
+        * compositing/overflow/subpixel-overflow-expected.txt: Added.
+        * compositing/overflow/subpixel-overflow.html: Added.
+        * platform/ios-sim/compositing/overflow/subpixel-overflow-expected.txt: Added.
+        * platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt:
+        This is a progression; the old code failed to take the scrollbar width into
+        account, and the new code does.
+
+
+2014-04-30  Simon Fraser  <simon.fra...@apple.com>
+
         Rebaseline compositing/overflow tests for iOS.
 
         * platform/ios-sim/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt:

Added: trunk/LayoutTests/compositing/overflow/subpixel-overflow-expected.txt (0 => 168078)


--- trunk/LayoutTests/compositing/overflow/subpixel-overflow-expected.txt	                        (rev 0)
+++ trunk/LayoutTests/compositing/overflow/subpixel-overflow-expected.txt	2014-05-01 02:15:17 UTC (rev 168078)
@@ -0,0 +1,6 @@
+Content
+ 
+Content
+ 
+Content
+

Added: trunk/LayoutTests/compositing/overflow/subpixel-overflow.html (0 => 168078)


--- trunk/LayoutTests/compositing/overflow/subpixel-overflow.html	                        (rev 0)
+++ trunk/LayoutTests/compositing/overflow/subpixel-overflow.html	2014-05-01 02:15:17 UTC (rev 168078)
@@ -0,0 +1,54 @@
+<!DOCTYPE html>
+
+<html>
+<head>
+    <style>
+        html {
+            -webkit-overflow-scrolling: touch;
+        }
+        
+        .container {
+            margin: 10px;
+            width: 200px;
+            border: 1px solid black;
+            overflow: auto;
+            display: inline-block;
+        }
+        
+        .contents {
+            width: 100%;
+        }
+    </style>
+    <script>
+        if (window.testRunner)
+            testRunner.dumpAsText();
+
+        window.addEventListener('load', function() {
+            if (window.testRunner)
+                document.getElementById('layers').innerHTML = window.internals.layerTreeAsText(document);
+        }, true);
+    </script>
+</head>
+<body>
+
+    <!-- None of these should be scrollable -->
+    <div class="container">
+        <div class="contents" style="height: 200.25px">
+            Content
+        </div>
+    </div>
+
+    <div class="container">
+        <div class="contents" style="height: 200.5px">
+            Content
+        </div>
+    </div>
+
+    <div class="container">
+        <div class="contents" style="height: 200.75px">
+            Content
+        </div>
+    </div>
+<pre id="layers"></pre>
+</body>
+</html>

Added: trunk/LayoutTests/platform/ios-sim/compositing/overflow/subpixel-overflow-expected.txt (0 => 168078)


--- trunk/LayoutTests/platform/ios-sim/compositing/overflow/subpixel-overflow-expected.txt	                        (rev 0)
+++ trunk/LayoutTests/platform/ios-sim/compositing/overflow/subpixel-overflow-expected.txt	2014-05-01 02:15:17 UTC (rev 168078)
@@ -0,0 +1,67 @@
+Content
+ 
+Content
+ 
+Content
+ (GraphicsLayer
+  (bounds 800.00 600.00)
+  (children 1
+    (GraphicsLayer
+      (bounds 800.00 600.00)
+      (children 3
+        (GraphicsLayer
+          (position 18.00 18.00)
+          (bounds 202.00 202.50)
+          (drawsContent 1)
+          (children 1
+            (GraphicsLayer
+              (position 1.00 1.00)
+              (bounds 200.00 200.00)
+              (children 1
+                (GraphicsLayer
+                  (bounds 200.00 200.00)
+                  (drawsContent 1)
+                )
+              )
+            )
+          )
+        )
+        (GraphicsLayer
+          (position 244.00 18.00)
+          (bounds 202.00 202.50)
+          (drawsContent 1)
+          (children 1
+            (GraphicsLayer
+              (position 1.00 1.00)
+              (bounds 200.00 201.00)
+              (children 1
+                (GraphicsLayer
+                  (bounds 200.00 201.00)
+                  (drawsContent 1)
+                )
+              )
+            )
+          )
+        )
+        (GraphicsLayer
+          (position 470.00 18.00)
+          (bounds 202.00 203.00)
+          (drawsContent 1)
+          (children 1
+            (GraphicsLayer
+              (position 1.00 1.00)
+              (bounds 200.00 201.00)
+              (children 1
+                (GraphicsLayer
+                  (bounds 200.00 201.00)
+                  (drawsContent 1)
+                )
+              )
+            )
+          )
+        )
+      )
+    )
+  )
+)
+

Modified: trunk/LayoutTests/platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt (168077 => 168078)


--- trunk/LayoutTests/platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt	2014-05-01 02:15:15 UTC (rev 168077)
+++ trunk/LayoutTests/platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt	2014-05-01 02:15:17 UTC (rev 168078)
@@ -12,7 +12,7 @@
           (children 4
             (GraphicsLayer
               (position 1.00 1.00)
-              (bounds 200.00 200.00)
+              (bounds 185.00 185.00)
               (children 1
                 (GraphicsLayer
                   (bounds 200.00 300.00)

Modified: trunk/Source/WebCore/ChangeLog (168077 => 168078)


--- trunk/Source/WebCore/ChangeLog	2014-05-01 02:15:15 UTC (rev 168077)
+++ trunk/Source/WebCore/ChangeLog	2014-05-01 02:15:17 UTC (rev 168078)
@@ -1,3 +1,27 @@
+2014-04-30  Simon Fraser  <simon.fra...@apple.com>
+
+        [iOS WK2] Some accerated overflow-scroll doesn't scroll correctly
+        https://bugs.webkit.org/show_bug.cgi?id=132375
+
+        Reviewed by Tim Horton.
+        
+        We set the size of the scrolling layer (which becomes the bounds of
+        the UIScrollView) to a non-pixel-snapped padding box size, but the
+        size of the contents layer is an integral-snapped scroll size.
+        This would result in a fractional difference between the two, which
+        makes us thing that the element is scrollable when it really is not.
+        
+        Fix by setting the size of the scroll layer to pixel snapped client size,
+        which is what we also use for scrollability computation.
+        
+        Added some FIXMEs in code that requires pixel snapping.
+        
+        Also use #if PLATFORM(IOS)/#else to bracket some code that never runs on iOS
+        but tries to do something similar to iOS-only code.
+
+        * rendering/RenderLayerBacking.cpp:
+        (WebCore::RenderLayerBacking::updateGraphicsLayerGeometry):
+
 2014-04-30  David Hyatt  <hy...@apple.com>
 
         REGRESSION (r168046): [New Multicolumn] Painting order is wrong for columns and fixed positioned elements

Modified: trunk/Source/WebCore/rendering/RenderLayerBacking.cpp (168077 => 168078)


--- trunk/Source/WebCore/rendering/RenderLayerBacking.cpp	2014-05-01 02:15:15 UTC (rev 168077)
+++ trunk/Source/WebCore/rendering/RenderLayerBacking.cpp	2014-05-01 02:15:17 UTC (rev 168078)
@@ -743,6 +743,7 @@
     if (compAncestor && compAncestor->backing()->hasClippingLayer()) {
         // If the compositing ancestor has a layer to clip children, we parent in that, and therefore
         // position relative to it.
+        // FIXME: need to do some pixel snapping here.
         LayoutRect clippingBox = clipBox(toRenderBox(compAncestor->renderer()));
         graphicsLayerParentLocation = clippingBox.location();
     } else if (compAncestor)
@@ -757,18 +758,19 @@
             renderBox->width() - renderBox->borderLeft() - renderBox->borderRight(),
             renderBox->height() - renderBox->borderTop() - renderBox->borderBottom());
 
-        LayoutSize scrollOffset = compAncestor->scrolledContentOffset();
+        IntSize scrollOffset = compAncestor->scrolledContentOffset();
+        // FIXME: pixel snap the padding box.
         graphicsLayerParentLocation = paddingBox.location() - scrollOffset;
     }
-#endif
-
+#else
     if (compAncestor && compAncestor->needsCompositedScrolling()) {
         RenderBox& renderBox = toRenderBox(compAncestor->renderer());
         LayoutSize scrollOffset = compAncestor->scrolledContentOffset();
         LayoutPoint scrollOrigin(renderBox.borderLeft(), renderBox.borderTop());
         graphicsLayerParentLocation = scrollOrigin - scrollOffset;
     }
-    
+#endif
+
     if (compAncestor && m_ancestorClippingLayer) {
         // Call calculateRects to get the backgroundRect which is what is used to clip the contents of this
         // layer. Note that we call it with temporaryClipRects = true because normally when computing clip rects
@@ -813,6 +815,7 @@
     // If we have a layer that clips children, position it.
     LayoutRect clippingBox;
     if (GraphicsLayer* clipLayer = clippingLayer()) {
+        // FIXME: need to do some pixel snapping here.
         clippingBox = clipBox(toRenderBox(renderer()));
         clipLayer->setPosition(FloatPoint(clippingBox.location() - localCompositingBounds.location()));
         clipLayer->setSize(clippingBox.size());
@@ -909,9 +912,11 @@
         LayoutRect paddingBox(renderBox.borderLeft(), renderBox.borderTop(), renderBox.width() - renderBox.borderLeft() - renderBox.borderRight(), renderBox.height() - renderBox.borderTop() - renderBox.borderBottom());
         LayoutSize scrollOffset = m_owningLayer.scrollOffset();
 
+        // FIXME: need to do some pixel snapping here.
         m_scrollingLayer->setPosition(FloatPoint(paddingBox.location() - localCompositingBounds.location()));
 
-        m_scrollingLayer->setSize(paddingBox.size());
+        IntSize pixelSnappedClientSize(renderBox.pixelSnappedClientWidth(), renderBox.pixelSnappedClientHeight());
+        m_scrollingLayer->setSize(pixelSnappedClientSize);
 #if PLATFORM(IOS)
         FloatSize oldScrollingLayerOffset = m_scrollingLayer->offsetFromRenderer();
         m_scrollingLayer->setOffsetFromRenderer(FloatPoint() - paddingBox.location());
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to