[Webkit-unassigned] [Bug 54219] Crash in WebCore::FrameLoader::continueLoadAfterNavigationPolicy

Mon Feb 14 15:32:44 PST 2011

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

--- Comment #7 from Charles Reis <creis at chromium.org>  2011-02-14 15:32:44 PST ---
(In reply to comment #6)
> Normally all page-initiated location changes are asynchronous, so we don't end up in this state of having more than one navigation in progress. One possible fix is to remove this special-casing of fragment changes here, and let them be handled like other navigations (which involves enqueuing a task on the NavigationScheduler queue, by the time that fires the previous navigation will be complete).

I can confirm that change would avoid the crash, but I'm not sure it'll catch all the ways we might get there.  For example, about:blank does a similar shortcut.

Nate and I were considering returning early from FrameLoader::loadURL if m_inStopAllLoaders is true.  There's already a check like that in FrameLoader::load, and it would be a good sanity check.

The biggest problem I'm facing right now is not being able to boil this down to a reduced test case.  The Ebay URL in comment 3 works reliably, but only on Windows.  I've written a test that puts an onload handler on a slow iframe, navigating to #foo once onload fires.  I can't seem to get it to fire, though.  Instead, FrameLoader::m_isComplete is true when we get to FrameLoader::checkCompleted (unlike in the Ebay example), so we never call FrameLoader::checkCallImplicitClose.  (See frame 1f in comment 3.)

I should have a patch as soon as I get the test working.

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