[Webkit-unassigned] [Bug 194538] Crash in WebCore::ScrollingTree::updateTreeFromStateNode

[bugzilla-daemon at webkit.org]

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

Ali Juma <ajuma at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ajuma at chromium.org

--- Comment #7 from Ali Juma <ajuma at chromium.org> ---
(In reply to Simon Fraser (smfr) from comment #6)
> Any information you can gather about reproducibility would help in the
> diagnosis.

We don't have specific repro steps, but we know that users that have our new session restoration logic enabled are running into this crash at a rate that's 30 times higher than other users, and are crashing much earlier -- the median process uptime when this particular crash occurs is about 16 seconds for those users, compared to 4.3 minutes for other users.

This new session restoration logic works by loading a sequence of file URLs that each return a page that can redirect to the actual site the user visited. So as the user navigates back/forward, we'd first visit that file URL, then get a redirect, and then load the actual URL. (We have to restore sessions in this weird way in order to workaround bug 169618.)

This approach has the side effect of adding process swaps. So suppose the user's actual history is:
a) www.google.com/search?q=cats
b) www.google.com/search?q=dogs
c) www.google.com/search?q=mice

And say that at startup, we restore this history and the user is now at (c). At this point, if the user taps on the back button, we'd first load our file URL that then redirects to (b). So ordinarily on a navigation from (c) to (b) there wouldn't be a process swap and we'd continue committing to the same ScrollTree, but with this change we swap to a different process for the file URL and then back to the original process after the redirect. And this time, when we continue in the original process, we're committing to a new scroll tree.

So my guess is that somehow we're winding up with a parent-less ScrollTreeNode at the end of all this. (And afaik, https://bugs.webkit.org/show_bug.cgi?id=193907 is not in 12.2 or 12.3, so we don't have the change there to track and remove unvisited nodes in ScrollingTree::commitTreeState.)

-- 
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/20190508/3c2ac8b2/attachment.html>