[Webkit-unassigned] [Bug 48809] Chromium WebKit API needs WebFrame::lastCommittedHistoryItem()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 9 08:51:55 PST 2010


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





--- Comment #19 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-11-09 08:51:55 PST ---
(In reply to comment #18)
> (In reply to comment #17)
> > Interesting-- this didn't turn out the way I expected.  The problem is that HistoryController's m_previousItem is null after the load commits, rather than being the last committed history item.  It gets set to null in HistoryController::updateForFrameLoadCompleted.  (As a result, WebFrameImpl::previousHistoryItem returns null when Chrome tries to send UpdateState messages, which leads to the bug I mentioned.  Details: http://code.google.com/p/chromium/issues/detail?id=62156)
> 
> A small clarification: m_previousItem always gets set to null, but it's at different times depending on whether it's a fragment navigation or not (which is why the Chrome bug only happens when navigating to a URL fragment).  For normal navigations, updateForFrameLoadCompleted gets called after we send the UpdateState message.  For fragment navigations, it gets called twice before we send the UpdateState message (preventing the message from getting sent).

I can't think of any good reason for nulling out m_previousItem.  Does anything actually break (layout test wise) if you make HistoryController::updateForFrameLoadCompleted() do nothing?  The comment in that function seems out-of-date.  It seems like the kind of thing that m_provisionalItem resolves.

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