- Revision
- 195664
- Author
- [email protected]
- Date
- 2016-01-27 05:21:05 -0800 (Wed, 27 Jan 2016)
Log Message
Merge r195445 - REGRESSION (r168244): Content in horizontal-bt page is offset such that only the end is viewable and there is a white gap at the top
https://bugs.webkit.org/show_bug.cgi?id=136019
Reviewed by Dan Bernstein.
Source/WebCore:
In horizontal-bt documents (where the page starts scrolled to the bottom, and scrolling up goes into negative scroll positions),
the position of the root content layer would be set incorrectly by the scrolling thread, resulting in misplaced
content.
Fix by having the renamed "yPositionForRootContentLayer" take scroll origin into
account, and being more consistent about using scrollOrigin to position this layer.
Test: fast/scrolling/programmatic-horizontal-bt-document-scroll.html
* page/FrameView.cpp:
(WebCore::FrameView::yPositionForFooterLayer): Moved
(WebCore::FrameView::positionForRootContentLayer): Take scrollOrigin, and subtract it from the computed value.
(WebCore::FrameView::yPositionForRootContentLayer): Renamed.
* page/FrameView.h:
* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll): We've already pushed the new scrollPosition onto the FrameView,
so we can just use the member function to compute the positionForContentsLayer.
* page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:
(WebCore::ScrollingTreeFrameScrollingNodeMac::setScrollLayerPosition): This is the bug fix; FrameView::positionForRootContentLayer()
now takes scrollOrigin into account.
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateRootLayerPosition): Rather than using the documentRect, position the root content layer
in terms of the scroll origin (which is -documentRect.location()).
Source/WebKit2:
Now call frameView.positionForRootContentLayer(), and add a FIXME questioning the
behavior in horizontal b-t documents. However, this code isn't hit now that we always
do extended backgrounds, so never have shadow layers.
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::shadowLayerPositionForFrame):
LayoutTests:
Test that scrolls a horizontal-bt document.
* fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html: Added.
* fast/scrolling/programmatic-horizontal-bt-document-scroll.html: Added.
Modified Paths
Added Paths
Diff
Modified: releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog 2016-01-27 13:21:05 UTC (rev 195664)
@@ -1,3 +1,15 @@
+2016-01-21 Simon Fraser <[email protected]>
+
+ REGRESSION (r168244): Content in horizontal-bt page is offset such that only the end is viewable and there is a white gap at the top
+ https://bugs.webkit.org/show_bug.cgi?id=136019
+
+ Reviewed by Dan Bernstein.
+
+ Test that scrolls a horizontal-bt document.
+
+ * fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html: Added.
+ * fast/scrolling/programmatic-horizontal-bt-document-scroll.html: Added.
+
2016-01-21 Said Abou-Hallawa <[email protected]>
A crash reproducible in Path::isEmpty() under RenderSVGShape::paint()
Added: releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html (0 => 195664)
--- releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html (rev 0)
+++ releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html 2016-01-27 13:21:05 UTC (rev 195664)
@@ -0,0 +1,32 @@
+<html>
+<head>
+ <style>
+ body {
+ margin: 0;
+ height: 1100px;
+ }
+ .origin {
+ position: absolute;
+ top: 500px;
+ left: 0;
+ width: 10px;
+ height: 10px;
+ background-color: blue;
+ }
+
+ #indicator {
+ position: absolute;
+ left: 0;
+ top: 0;
+ width: 100px;
+ height: 100px;
+ background-color: green;
+ }
+ </style>
+</head>
+<body>
+ <div class="origin"></div>
+ <div id="indicator"></div>
+ <div id="result"></div>
+</body>
+</html>
Added: releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll.html (0 => 195664)
--- releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll.html (rev 0)
+++ releases/WebKitGTK/webkit-2.10/LayoutTests/fast/scrolling/programmatic-horizontal-bt-document-scroll.html 2016-01-27 13:21:05 UTC (rev 195664)
@@ -0,0 +1,39 @@
+<html style="-webkit-writing-mode: horizontal-bt;">
+<head>
+ <style>
+ body {
+ margin: 0;
+ }
+ .origin {
+ position: absolute;
+ top: 0;
+ left: 0;
+ width: 10px;
+ height: 10px;
+ background-color: blue;
+ }
+
+ #indicator {
+ position: absolute;
+ left: 0;
+ top: -500px;
+ width: 100px;
+ height: 100px;
+ background-color: green;
+ }
+ </style>
+ <script>
+ function runTest()
+ {
+ document.scrollingElement.scrollTop = -500;
+ }
+
+ window.addEventListener('load', runTest, false);
+ </script>
+</head>
+<body>
+ <div class="origin"></div>
+ <div id="indicator"></div>
+ <div id="result"></div>
+</body>
+</html>
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/ChangeLog (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/ChangeLog 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/ChangeLog 2016-01-27 13:21:05 UTC (rev 195664)
@@ -1,3 +1,34 @@
+2016-01-21 Simon Fraser <[email protected]>
+
+ REGRESSION (r168244): Content in horizontal-bt page is offset such that only the end is viewable and there is a white gap at the top
+ https://bugs.webkit.org/show_bug.cgi?id=136019
+
+ Reviewed by Dan Bernstein.
+
+ In horizontal-bt documents (where the page starts scrolled to the bottom, and scrolling up goes into negative scroll positions),
+ the position of the root content layer would be set incorrectly by the scrolling thread, resulting in misplaced
+ content.
+
+ Fix by having the renamed "yPositionForRootContentLayer" take scroll origin into
+ account, and being more consistent about using scrollOrigin to position this layer.
+
+ Test: fast/scrolling/programmatic-horizontal-bt-document-scroll.html
+
+ * page/FrameView.cpp:
+ (WebCore::FrameView::yPositionForFooterLayer): Moved
+ (WebCore::FrameView::positionForRootContentLayer): Take scrollOrigin, and subtract it from the computed value.
+ (WebCore::FrameView::yPositionForRootContentLayer): Renamed.
+ * page/FrameView.h:
+ * page/scrolling/AsyncScrollingCoordinator.cpp:
+ (WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll): We've already pushed the new scrollPosition onto the FrameView,
+ so we can just use the member function to compute the positionForContentsLayer.
+ * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:
+ (WebCore::ScrollingTreeFrameScrollingNodeMac::setScrollLayerPosition): This is the bug fix; FrameView::positionForRootContentLayer()
+ now takes scrollOrigin into account.
+ * rendering/RenderLayerCompositor.cpp:
+ (WebCore::RenderLayerCompositor::updateRootLayerPosition): Rather than using the documentRect, position the root content layer
+ in terms of the scroll origin (which is -documentRect.location()).
+
2016-01-21 Said Abou-Hallawa <[email protected]>
A crash reproducible in Path::isEmpty() under RenderSVGShape::paint()
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.cpp (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.cpp 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.cpp 2016-01-27 13:21:05 UTC (rev 195664)
@@ -1761,19 +1761,19 @@
return scrollY;
}
-float FrameView::yPositionForRootContentLayer(const FloatPoint& scrollPosition, float topContentInset, float headerHeight)
+float FrameView::yPositionForFooterLayer(const FloatPoint& scrollPosition, float topContentInset, float totalContentsHeight, float footerHeight)
{
- return yPositionForHeaderLayer(scrollPosition, topContentInset) + headerHeight;
+ return yPositionForHeaderLayer(scrollPosition, topContentInset) + totalContentsHeight - footerHeight;
}
-float FrameView::yPositionForFooterLayer(const FloatPoint& scrollPosition, float topContentInset, float totalContentsHeight, float footerHeight)
+FloatPoint FrameView::positionForRootContentLayer(const FloatPoint& scrollPosition, const FloatPoint& scrollOrigin, float topContentInset, float headerHeight)
{
- return yPositionForHeaderLayer(scrollPosition, topContentInset) + totalContentsHeight - footerHeight;
+ return FloatPoint(0, yPositionForHeaderLayer(scrollPosition, topContentInset) + headerHeight) - toFloatSize(scrollOrigin);
}
-float FrameView::yPositionForRootContentLayer() const
+FloatPoint FrameView::positionForRootContentLayer() const
{
- return yPositionForRootContentLayer(scrollPosition(), topContentInset(), headerHeight());
+ return positionForRootContentLayer(scrollPosition(), scrollOrigin(), topContentInset(), headerHeight());
}
#if PLATFORM(IOS)
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.h (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.h 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/page/FrameView.h 2016-01-27 13:21:05 UTC (rev 195664)
@@ -289,8 +289,8 @@
// These layers are positioned differently when there is a topContentInset, a header, or a footer. These value need to be computed
// on both the main thread and the scrolling thread.
static float yPositionForInsetClipLayer(const FloatPoint& scrollPosition, float topContentInset);
- WEBCORE_EXPORT static float yPositionForRootContentLayer(const FloatPoint& scrollPosition, float topContentInset, float headerHeight);
- WEBCORE_EXPORT float yPositionForRootContentLayer() const;
+ WEBCORE_EXPORT static FloatPoint positionForRootContentLayer(const FloatPoint& scrollPosition, const FloatPoint& scrollOrigin, float topContentInset, float headerHeight);
+ WEBCORE_EXPORT FloatPoint positionForRootContentLayer() const;
static float yPositionForHeaderLayer(const FloatPoint& scrollPosition, float topContentInset);
static float yPositionForFooterLayer(const FloatPoint& scrollPosition, float topContentInset, float totalContentsHeight, float footerHeight);
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp 2016-01-27 13:21:05 UTC (rev 195664)
@@ -329,10 +329,9 @@
float topContentInset = frameView.topContentInset();
FloatPoint positionForInsetClipLayer = FloatPoint(0, FrameView::yPositionForInsetClipLayer(scrollPosition, topContentInset));
- FloatPoint positionForContentsLayer = FloatPoint(scrolledContentsLayer->position().x(),
- FrameView::yPositionForRootContentLayer(scrollPosition, topContentInset, frameView.headerHeight()));
- FloatPoint positionForHeaderLayer = FloatPoint(scrollOffsetForFixed.width(), FrameView::yPositionForHeaderLayer(scrollPosition, topContentInset));
- FloatPoint positionForFooterLayer = FloatPoint(scrollOffsetForFixed.width(),
+ FloatPoint positionForContentsLayer = frameView.positionForRootContentLayer();
+ FloatPoint positionForHeaderLayer = FloatPoint(scrollPositionForFixed.x(), FrameView::yPositionForHeaderLayer(scrollPosition, topContentInset));
+ FloatPoint positionForFooterLayer = FloatPoint(scrollPositionForFixed.x(),
FrameView::yPositionForFooterLayer(scrollPosition, topContentInset, frameView.totalContentsSize().height(), frameView.footerHeight()));
if (programmaticScroll || scrollingLayerPositionAction == SetScrollingLayerPosition) {
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm 2016-01-27 13:21:05 UTC (rev 195664)
@@ -412,8 +412,7 @@
float topContentInset = this->topContentInset();
if (m_insetClipLayer && m_scrolledContentsLayer && topContentInset) {
m_insetClipLayer.get().position = FloatPoint(0, FrameView::yPositionForInsetClipLayer(position, topContentInset));
- m_scrolledContentsLayer.get().position = FloatPoint(m_scrolledContentsLayer.get().position.x,
- FrameView::yPositionForRootContentLayer(position, topContentInset, headerHeight()));
+ m_scrolledContentsLayer.get().position = FrameView::positionForRootContentLayer(position, scrollOrigin(), topContentInset, headerHeight());
if (m_contentShadowLayer)
m_contentShadowLayer.get().position = m_scrolledContentsLayer.get().position;
}
Modified: releases/WebKitGTK/webkit-2.10/Source/WebCore/rendering/RenderLayerCompositor.cpp (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebCore/rendering/RenderLayerCompositor.cpp 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebCore/rendering/RenderLayerCompositor.cpp 2016-01-27 13:21:05 UTC (rev 195664)
@@ -2157,9 +2157,8 @@
void RenderLayerCompositor::updateRootLayerPosition()
{
if (m_rootContentLayer) {
- const IntRect& documentRect = m_renderView.documentRect();
- m_rootContentLayer->setSize(documentRect.size());
- m_rootContentLayer->setPosition(FloatPoint(documentRect.x(), documentRect.y() + m_renderView.frameView().yPositionForRootContentLayer()));
+ m_rootContentLayer->setSize(m_renderView.frameView().contentsSize());
+ m_rootContentLayer->setPosition(m_renderView.frameView().positionForRootContentLayer());
m_rootContentLayer->setAnchorPoint(FloatPoint3D());
}
if (m_clipLayer) {
Modified: releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog 2016-01-27 13:21:05 UTC (rev 195664)
@@ -1,3 +1,17 @@
+2016-01-21 Simon Fraser <[email protected]>
+
+ REGRESSION (r168244): Content in horizontal-bt page is offset such that only the end is viewable and there is a white gap at the top
+ https://bugs.webkit.org/show_bug.cgi?id=136019
+
+ Reviewed by Dan Bernstein.
+
+ Now call frameView.positionForRootContentLayer(), and add a FIXME questioning the
+ behavior in horizontal b-t documents. However, this code isn't hit now that we always
+ do extended backgrounds, so never have shadow layers.
+
+ * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
+ (WebKit::shadowLayerPositionForFrame):
+
2016-01-20 Carlos Garcia Campos <[email protected]>
Unreviewed. Update OptionsGTK.cmake and NEWS for 2.10.5 release.
Modified: releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm (195663 => 195664)
--- releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm 2016-01-27 12:34:15 UTC (rev 195663)
+++ releases/WebKitGTK/webkit-2.10/Source/WebKit2/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm 2016-01-27 13:21:05 UTC (rev 195664)
@@ -703,7 +703,8 @@
static FloatPoint shadowLayerPositionForFrame(FrameView& frameView, FloatPoint origin)
{
- FloatPoint position = frameView.renderView()->documentRect().location() + FloatPoint(0, frameView.yPositionForRootContentLayer());
+ // FIXME: correct for b-t documents?
+ FloatPoint position = frameView.positionForRootContentLayer();
return position + origin.expandedTo(FloatPoint());
}
