Title: [209745] trunk/Source/WebCore
- Revision
- 209745
- Author
- [email protected]
- Date
- 2016-12-12 16:35:28 -0800 (Mon, 12 Dec 2016)
Log Message
Infinite recursion when viewport is set to the size of the content but the content overflows the viewport.
https://bugs.webkit.org/show_bug.cgi?id=165775
rdar://problem/29366628
Reviewed by Simon Fraser.
In certain cases when the viewport is sized to accomodate the content and
the content always overflows the viewport, we might end up in recursive FrameView::layout calls.
This is specific to content with viewport units, because we always invalidate elements with vw/vh units on
viewport size change. However if this viewport size change is in response to content size change (layout),
invalidating elements could trigger synchronous layout, while we are still inside this current layout.
This is very similar to the m_setNeedsLayoutWasDeferred case and they should eventually be merged.
It also means that we might be behind by one layout on elements with vw/vh units (fixed layout only though).
Currently not testable.
* page/FrameView.cpp:
(WebCore::FrameView::availableContentSizeChanged):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (209744 => 209745)
--- trunk/Source/WebCore/ChangeLog 2016-12-13 00:28:18 UTC (rev 209744)
+++ trunk/Source/WebCore/ChangeLog 2016-12-13 00:35:28 UTC (rev 209745)
@@ -1,3 +1,24 @@
+2016-12-12 Zalan Bujtas <[email protected]>
+
+ Infinite recursion when viewport is set to the size of the content but the content overflows the viewport.
+ https://bugs.webkit.org/show_bug.cgi?id=165775
+ rdar://problem/29366628
+
+ Reviewed by Simon Fraser.
+
+ In certain cases when the viewport is sized to accomodate the content and
+ the content always overflows the viewport, we might end up in recursive FrameView::layout calls.
+ This is specific to content with viewport units, because we always invalidate elements with vw/vh units on
+ viewport size change. However if this viewport size change is in response to content size change (layout),
+ invalidating elements could trigger synchronous layout, while we are still inside this current layout.
+ This is very similar to the m_setNeedsLayoutWasDeferred case and they should eventually be merged.
+ It also means that we might be behind by one layout on elements with vw/vh units (fixed layout only though).
+
+ Currently not testable.
+
+ * page/FrameView.cpp:
+ (WebCore::FrameView::availableContentSizeChanged):
+
2016-12-12 Keith Rollin <[email protected]>
Memory warning logging appears to capture resident footprint, missing compress/swap.
Modified: trunk/Source/WebCore/page/FrameView.cpp (209744 => 209745)
--- trunk/Source/WebCore/page/FrameView.cpp 2016-12-13 00:28:18 UTC (rev 209744)
+++ trunk/Source/WebCore/page/FrameView.cpp 2016-12-13 00:35:28 UTC (rev 209745)
@@ -2671,8 +2671,13 @@
void FrameView::availableContentSizeChanged(AvailableSizeChangeReason reason)
{
- if (Document* document = frame().document())
- document->updateViewportUnitsOnResize();
+ if (Document* document = frame().document()) {
+ // FIXME: Merge this logic with m_setNeedsLayoutWasDeferred and find a more appropriate
+ // way of handling potential recursive layouts when the viewport is resized to accomodate
+ // the content but the content always overflows the viewport. See webkit.org/b/165781.
+ if (!(layoutPhase() == InViewSizeAdjust && useFixedLayout()))
+ document->updateViewportUnitsOnResize();
+ }
updateLayoutViewport();
setNeedsLayout();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
