Changeset 151803 in webkit

Timestamp:

Jun 20, 2013, 2:28:15 PM (12 years ago)

Author:

Simon Fraser

Message:

Sticky elements are missing or misplaced sometimes when reloading a page that scrolls to a named anchor
​https://bugs.webkit.org/show_bug.cgi?id=117819

Reviewed by Anders Carlsson.

At the end of FrameView::performPostLayoutTasks() we call scrollToAnchor() which attempts
to restore the scroll position to a named anchor, even when the document has been
changed by layout. This ends up in a call to ScrollView::scrollTo(), which in turn
calls repaintFixedElementsAfterScrolling(). However, repaintFixedElementsAfterScrolling()
would bail if m_nestedLayoutCount != 0, so we never updated layer positions which
depend on scroll position (but which would not be updated by layout, since their
renderers are not marked for layout when scrolling happens).

We've solved this problem once before in updateFixedElementsAfterScrolling() which
checks for m_nestedLayoutCount <= 1, so that we do work on the outermost nested layout.
Apply that same fix to repaintFixedElementsAfterScrolling().

Very timing-dependent, so hard to make a test.

• page/FrameView.cpp:

(WebCore::FrameView::repaintFixedElementsAfterScrolling):

Location:

trunk/Source/WebCore

Files:

• ChangeLog (modified) (1 diff)
• page/FrameView.cpp (modified) (1 diff)

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2013-06-20  Simon Fraser  <simon.fraser@apple.com>
+
+        Sticky elements are missing or misplaced sometimes when reloading a page that scrolls to a named anchor
+        https://bugs.webkit.org/show_bug.cgi?id=117819
+
+        Reviewed by Anders Carlsson.
+        
+        At the end of FrameView::performPostLayoutTasks() we call scrollToAnchor() which attempts
+        to restore the scroll position to a named anchor, even when the document has been
+        changed by layout. This ends up in a call to ScrollView::scrollTo(), which in turn
+        calls repaintFixedElementsAfterScrolling(). However, repaintFixedElementsAfterScrolling()
+        would bail if m_nestedLayoutCount != 0, so we never updated layer positions which
+        depend on scroll position (but which would not be updated by layout, since their
+        renderers are not marked for layout when scrolling happens).
+        
+        We've solved this problem once before in updateFixedElementsAfterScrolling() which
+        checks for m_nestedLayoutCount <= 1, so that we do work on the outermost nested layout.
+        Apply that same fix to repaintFixedElementsAfterScrolling().
+
+        Very timing-dependent, so hard to make a test.
+
+        * page/FrameView.cpp:
+        (WebCore::FrameView::repaintFixedElementsAfterScrolling):
+
 2013-06-20  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>
 

trunk/Source/WebCore/page/FrameView.cpp

@@ -2008 +2008 @@
     // For fixed position elements, update widget positions and compositing layers after scrolling,
     // but only if we're not inside of layout.
-    if (!m_nestedLayoutCount && hasViewportConstrainedObjects()) {
+    if (m_nestedLayoutCount <= 1 && hasViewportConstrainedObjects()) {
         if (RenderView* renderView = this->renderView()) {
             renderView->updateWidgetPositions();