[Webkit-unassigned] [Bug 48809] Update correct content state during back/forward navigations

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Nov 15 16:00:36 PST 2010


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





--- Comment #32 from Charles Reis <creis at chromium.org>  2010-11-15 16:00:35 PST ---
(In reply to comment #31)
> (From update of attachment 73802 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=73802&action=review
> 
> > WebCore/loader/FrameLoader.cpp:1164
> > +    m_client->dispatchDidNavigateWithinPage();
> 
> Moving this here seems wrong to me.  This notification is meant to be
> generated after the within-page navigation completes.  I'm concerned
> that checkCompleted and checkLoadCompleted change our state in ways
> that should be observable from dispatchDidNavigateWithinPage.  For
> example, it looks like checkCompleted may generate a readystatechange
> event on the document.
> 
> It still seems to me that the right solution is to not clear m_previousItem.
> Given your change to setCurrentItem, does the forward navigation issue go
> away by any chance?  Can you try to unravel what is going on there?
> 
> I can point to places in HistoryController that assume m_previousItem will
> be valid.  See HistoryController::createItemTree.

Yes, with my change to setCurrentItem, it still works in most cases if we revert the FrameLoader change and don't clear m_previousItem in updateForFrameLoadCompleted.  There's a few layout tests that crash or fail now (e.g., due to the ASSERT in recursiveGoToItem), but I'll take a closer look at the assumptions to see if I can fix them.

For reference, I'm seeing fast/history/history-back-within-subframe-hash.html crash and fast/history/saves-state-after-fragment-nav.html fail.

-- 
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