[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