[Webkit-unassigned] [Bug 195037] [iOS] REGRESSION(r238490?): Safari sometimes shows blank page until a cross site navigation or re-opening the tab

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=195037

--- Comment #1 from Ryosuke Niwa <rniwa at webkit.org> ---
I was able to reproduce this issue on my phone other day, and upon detailed analysis, we came to conclusion that LayerTreeFreezeReason::ProcessSuspended is set in the affected WebPage, causing RemoteLayerTreeDrawingArea:: m_isFlushingSuspended to remain true, even though the page is clearly visible and I was actively interacting with it. This resulted in the layer tree to be never committed as RemoteLayerTreeDrawingArea::scheduleCompositingLayerFlush() would exit early in the first branch:

void RemoteLayerTreeDrawingArea::scheduleCompositingLayerFlush()
{
    if (m_isFlushingSuspended) {
        m_isLayerFlushThrottlingTemporarilyDisabledForInteraction = false;
        m_hasDeferredFlush = true;
        return;
    }
    if (m_isLayerFlushThrottlingTemporarilyDisabledForInteraction) {
        m_isLayerFlushThrottlingTemporarilyDisabledForInteraction = false;
        scheduleCompositingLayerFlushImmediately();
        return;
    }
...
}

It means that WebProcess::freezeAllLayerTrees() was called but WebProcess::unfreezeAllLayerTrees() was somehow never called in this web content process.

All evidence points to that ProcessThrottler in UI process is suspending the process but never waking up since all calls to WebProcess::freezeAllLayerTrees() and WebProcess::unfreezeAllLayerTrees() originate from ProcessThrottler. In fact, the console log on my phone indicated that the process was releasing the foreground assertion but never regaining its foreground status.

However, Antti pointed out to me that he recently refactored WebPage::freezeLayerTree to use a OptionSet instead of relying upon a boolean argument and some boolean states of WebPage in https://trac.webkit.org/changeset/238490. Prior to this change, WebProcess::unfreezeAllLayerTrees() was necessary as long as WebPage::didCompletePageTransition, WebPage::endPrinting, or WebPage::applicationWillEnterForeground was called. Because WebPage::didCompletePageTransition would happen on almost every page load, it's possible that prior to this code change, iOS Safari was suffering from the same problem but the symptom was never surfacing as a end-user visible bug because WebPage::didCompletePageTransition would eventually come around to fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190226/f7dc8bda/attachment.html>