⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 195445 in webkit


Ignore:
Timestamp:
Jan 21, 2016, 10:45:05 PM (11 years ago)
Author:
Simon Fraser
Message:

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.
Location:
trunk
Files:
2 added
9 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r195443 r195445  
     12016-01-21  Simon Fraser  <simon.fraser@apple.com>
     2
     3        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
     4        https://bugs.webkit.org/show_bug.cgi?id=136019
     5
     6        Reviewed by Dan Bernstein.
     7
     8        Test that scrolls a horizontal-bt document.
     9
     10        * fast/scrolling/programmatic-horizontal-bt-document-scroll-expected.html: Added.
     11        * fast/scrolling/programmatic-horizontal-bt-document-scroll.html: Added.
     12
    1132016-01-21  Brady Eidson  <beidson@apple.com>
    214

  • trunk/Source/WebCore/ChangeLog

    r195443 r195445  
     12016-01-21  Simon Fraser  <simon.fraser@apple.com>
     2
     3        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
     4        https://bugs.webkit.org/show_bug.cgi?id=136019
     5
     6        Reviewed by Dan Bernstein.
     7
     8        In horizontal-bt documents (where the page starts scrolled to the bottom, and scrolling up goes into negative scroll positions),
     9        the position of the root content layer would be set incorrectly by the scrolling thread, resulting in misplaced
     10        content.
     11
     12        Fix by having the renamed "yPositionForRootContentLayer" take scroll origin into
     13        account, and being more consistent about using scrollOrigin to position this layer.
     14
     15        Test: fast/scrolling/programmatic-horizontal-bt-document-scroll.html
     16
     17        * page/FrameView.cpp:
     18        (WebCore::FrameView::yPositionForFooterLayer): Moved
     19        (WebCore::FrameView::positionForRootContentLayer): Take scrollOrigin, and subtract it from the computed value.
     20        (WebCore::FrameView::yPositionForRootContentLayer): Renamed.
     21        * page/FrameView.h:
     22        * page/scrolling/AsyncScrollingCoordinator.cpp:
     23        (WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll): We've already pushed the new scrollPosition onto the FrameView,
     24        so we can just use the member function to compute the positionForContentsLayer.
     25        * page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:
     26        (WebCore::ScrollingTreeFrameScrollingNodeMac::setScrollLayerPosition): This is the bug fix; FrameView::positionForRootContentLayer()
     27        now takes scrollOrigin into account.
     28        * rendering/RenderLayerCompositor.cpp:
     29        (WebCore::RenderLayerCompositor::updateRootLayerPosition): Rather than using the documentRect, position the root content layer
     30        in terms of the scroll origin (which is -documentRect.location()).
     31
    1322016-01-21  Brady Eidson  <beidson@apple.com>
    233

  • trunk/Source/WebCore/page/FrameView.cpp

    r195142 r195445  
    17671767}
    17681768
    1769 float FrameView::yPositionForRootContentLayer(const FloatPoint& scrollPosition, float topContentInset, float headerHeight)
    1770 {
    1771     return yPositionForHeaderLayer(scrollPosition, topContentInset) + headerHeight;
    1772 }
    1773 
    17741769float FrameView::yPositionForFooterLayer(const FloatPoint& scrollPosition, float topContentInset, float totalContentsHeight, float footerHeight)
    17751770{
    … …  
    17771772}
    17781773
    1779 float FrameView::yPositionForRootContentLayer() const
    1780 {
    1781     return yPositionForRootContentLayer(scrollPosition(), topContentInset(), headerHeight());
     1774FloatPoint FrameView::positionForRootContentLayer(const FloatPoint& scrollPosition, const FloatPoint& scrollOrigin, float topContentInset, float headerHeight)
     1775{
     1776    return FloatPoint(0, yPositionForHeaderLayer(scrollPosition, topContentInset) + headerHeight) - toFloatSize(scrollOrigin);
     1777}
     1778
     1779FloatPoint FrameView::positionForRootContentLayer() const
     1780{
     1781    return positionForRootContentLayer(scrollPosition(), scrollOrigin(), topContentInset(), headerHeight());
    17821782}
    17831783

  • trunk/Source/WebCore/page/FrameView.h

    r194667 r195445  
    288288    // on both the main thread and the scrolling thread.
    289289    static float yPositionForInsetClipLayer(const FloatPoint& scrollPosition, float topContentInset);
    290     WEBCORE_EXPORT static float yPositionForRootContentLayer(const FloatPoint& scrollPosition, float topContentInset, float headerHeight);
    291     WEBCORE_EXPORT float yPositionForRootContentLayer() const;
     290    WEBCORE_EXPORT static FloatPoint positionForRootContentLayer(const FloatPoint& scrollPosition, const FloatPoint& scrollOrigin, float topContentInset, float headerHeight);
     291    WEBCORE_EXPORT FloatPoint positionForRootContentLayer() const;
    292292
    293293    static float yPositionForHeaderLayer(const FloatPoint& scrollPosition, float topContentInset);

  • trunk/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp

    r194442 r195445  
    324324            float topContentInset = frameView.topContentInset();
    325325            FloatPoint positionForInsetClipLayer = FloatPoint(0, FrameView::yPositionForInsetClipLayer(scrollPosition, topContentInset));
    326             FloatPoint positionForContentsLayer = FloatPoint(scrolledContentsLayer->position().x(),
    327                 FrameView::yPositionForRootContentLayer(scrollPosition, topContentInset, frameView.headerHeight()));
     326            FloatPoint positionForContentsLayer = frameView.positionForRootContentLayer();
    328327            FloatPoint positionForHeaderLayer = FloatPoint(scrollPositionForFixed.x(), FrameView::yPositionForHeaderLayer(scrollPosition, topContentInset));
    329328            FloatPoint positionForFooterLayer = FloatPoint(scrollPositionForFixed.x(),

  • trunk/Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm

    r194502 r195445  
    405405    if (m_insetClipLayer && m_scrolledContentsLayer && topContentInset) {
    406406        m_insetClipLayer.get().position = FloatPoint(0, FrameView::yPositionForInsetClipLayer(position, topContentInset));
    407         m_scrolledContentsLayer.get().position = FloatPoint(m_scrolledContentsLayer.get().position.x,
    408             FrameView::yPositionForRootContentLayer(position, topContentInset, headerHeight()));
     407        m_scrolledContentsLayer.get().position = FrameView::positionForRootContentLayer(position, scrollOrigin(), topContentInset, headerHeight());
    409408        if (m_contentShadowLayer)
    410409            m_contentShadowLayer.get().position = m_scrolledContentsLayer.get().position;

  • trunk/Source/WebCore/rendering/RenderLayerCompositor.cpp

    r194825 r195445  
    21222122{
    21232123    if (m_rootContentLayer) {
    2124         const IntRect& documentRect = m_renderView.documentRect();
    2125         m_rootContentLayer->setSize(documentRect.size());       
    2126         m_rootContentLayer->setPosition(FloatPoint(documentRect.x(), documentRect.y() + m_renderView.frameView().yPositionForRootContentLayer()));
     2124        m_rootContentLayer->setSize(m_renderView.frameView().contentsSize());
     2125        m_rootContentLayer->setPosition(m_renderView.frameView().positionForRootContentLayer());
    21272126        m_rootContentLayer->setAnchorPoint(FloatPoint3D());
    21282127    }

  • trunk/Source/WebKit2/ChangeLog

    r195429 r195445  
     12016-01-21  Simon Fraser  <simon.fraser@apple.com>
     2
     3        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
     4        https://bugs.webkit.org/show_bug.cgi?id=136019
     5
     6        Reviewed by Dan Bernstein.
     7
     8        Now call frameView.positionForRootContentLayer(), and add a FIXME questioning the
     9        behavior in horizontal b-t documents. However, this code isn't hit now that we always
     10        do extended backgrounds, so never have shadow layers.
     11
     12        * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
     13        (WebKit::shadowLayerPositionForFrame):
     14
    1152016-01-21  Dean Jackson  <dino@apple.com>
    216

  • trunk/Source/WebKit2/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm

    r194448 r195445  
    694694static FloatPoint shadowLayerPositionForFrame(FrameView& frameView, FloatPoint origin)
    695695{
    696     FloatPoint position = frameView.renderView()->documentRect().location() + FloatPoint(0, frameView.yPositionForRootContentLayer());
     696    // FIXME: correct for b-t documents?
     697    FloatPoint position = frameView.positionForRootContentLayer();
    697698    return position + origin.expandedTo(FloatPoint());
    698699}
Note: See TracChangeset for help on using the changeset viewer.