[Webkit-unassigned] [Bug 30839] REGRESSION: crashes in WebCore::RedirectScheduler::timerFired(WebCore::Timer<WebCore::RedirectScheduler>*)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 27 17:41:14 PDT 2009


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


Darin Adler <darin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abarth at webkit.org




--- Comment #7 from Darin Adler <darin at apple.com>  2009-10-27 17:41:14 PDT ---
I see nothing that would guarantee that RedirectScheduleer::clear() is called
on the frames in a page when a page is destroyed.

The Frame::pageDestroyed() function calls loader()->checkLoadComplete() on the
parent frame but otherwise does nothing to stop the loader or clear the
redirect scheduler.

There’s also CachedFrame::destroy(). My guess is that case already guarantees
the loading has stopped somehow, including clearing the redirect scheduler, but
I'm not sure about that case.

The lowest level way to fix this would be to just check for 0 in the timerFired
function. Moving up the food chain, we could add a call to
RedirectScheduler::clear() in Frame::detachFromPage(). Or we could add one to
Frame::pageDestroyed() if we satisfy ourselves it’s not needed in
CachedFrame::destroy().

If we could figure out a clean existing or new higher level concept of when we
should stop loading due to the page going away, including clearing the
scheduled redirect, then we could just fix that to work properly.

Given we can’t reproduce the crash reliably, we may not be able to make a test
case, but this is trivial to fix!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list