Title: [151803] trunk/Source/WebCore
- Revision
- 151803
- Author
- [email protected]
- Date
- 2013-06-20 14:28:15 -0700 (Thu, 20 Jun 2013)
Log 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):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (151802 => 151803)
--- trunk/Source/WebCore/ChangeLog 2013-06-20 21:18:39 UTC (rev 151802)
+++ trunk/Source/WebCore/ChangeLog 2013-06-20 21:28:15 UTC (rev 151803)
@@ -1,3 +1,27 @@
+2013-06-20 Simon Fraser <[email protected]>
+
+ 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 <[email protected]>
HashSet: reverse the order of the template arguments at alternate 'find', 'contains' and 'add' methods
Modified: trunk/Source/WebCore/page/FrameView.cpp (151802 => 151803)
--- trunk/Source/WebCore/page/FrameView.cpp 2013-06-20 21:18:39 UTC (rev 151802)
+++ trunk/Source/WebCore/page/FrameView.cpp 2013-06-20 21:28:15 UTC (rev 151803)
@@ -2007,7 +2007,7 @@
{
// 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();
renderView->layer()->updateLayerPositionsAfterDocumentScroll();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
