<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - View scale changes are temporarily lost after restoring a page from the page cache"
href="https://bugs.webkit.org/show_bug.cgi?id=144934#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - View scale changes are temporarily lost after restoring a page from the page cache"
href="https://bugs.webkit.org/show_bug.cgi?id=144934">bug 144934</a>
from <span class="vcard"><a class="email" href="mailto:thorton@apple.com" title="Tim Horton <thorton@apple.com>"> <span class="fn">Tim Horton</span></a>
</span></b>
<pre>There's a second hilarity here where, once we fix HistoryController to apply the new viewScale when restoring the pageScale, since the Page's m_pageScaleFactor is already updated to the new value, setPageScaleFactor() will bail and fail to update the scale on the tile container layer.
This never mattered before because the scale that HistoryController handed to setPageScaleFactor() was always the same as the scale already applied to the layer that is coming back from the PageCache (which is no longer true).
I've worked around this by notifying the frames of a pageScaleFactor change if either of the scales is now different from what was stored in the history item -- I'm not sure this is the best fix. Alternatively, we could make setPageScaleFactor take a "no really, I mean it" parameter...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>