<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[209745] trunk/Source/WebCore</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.webkit.org/projects/webkit/changeset/209745">209745</a></dd>
<dt>Author</dt> <dd>zalan@apple.com</dd>
<dt>Date</dt> <dd>2016-12-12 16:35:28 -0800 (Mon, 12 Dec 2016)</dd>
</dl>
<h3>Log Message</h3>
<pre>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):</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceWebCoreChangeLog">trunk/Source/WebCore/ChangeLog</a></li>
<li><a href="#trunkSourceWebCorepageFrameViewcpp">trunk/Source/WebCore/page/FrameView.cpp</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceWebCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/WebCore/ChangeLog (209744 => 209745)</h4>
<pre class="diff"><span>
<span class="info">--- 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)
</span><span class="lines">@@ -1,3 +1,24 @@
</span><ins>+2016-12-12 Zalan Bujtas <zalan@apple.com>
+
+ 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):
+
</ins><span class="cx"> 2016-12-12 Keith Rollin <krollin@apple.com>
</span><span class="cx">
</span><span class="cx"> Memory warning logging appears to capture resident footprint, missing compress/swap.
</span></span></pre></div>
<a id="trunkSourceWebCorepageFrameViewcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/WebCore/page/FrameView.cpp (209744 => 209745)</h4>
<pre class="diff"><span>
<span class="info">--- 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)
</span><span class="lines">@@ -2671,8 +2671,13 @@
</span><span class="cx">
</span><span class="cx"> void FrameView::availableContentSizeChanged(AvailableSizeChangeReason reason)
</span><span class="cx"> {
</span><del>- if (Document* document = frame().document())
- document->updateViewportUnitsOnResize();
</del><ins>+ 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();
+ }
</ins><span class="cx">
</span><span class="cx"> updateLayoutViewport();
</span><span class="cx"> setNeedsLayout();
</span></span></pre>
</div>
</div>
</body>
</html>