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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 4 17:50:49 PDT 2010


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





--- Comment #9 from Charles Reis <creis at chromium.org>  2010-11-04 17:50:49 PST ---
(In reply to comment #7)
> Oh, I see.  Perhaps we should not be setting the previous HistoryItem until we successfully commit.  I think it may confuse other things if previousHistoryItem is not reliably the last committed HistoryItem.
> 
> The HistoryController appears to have the concept of a provisional HistoryItem that is only set once we commit.  See HistoryController::updateForCommit.
> 
> Perhaps you should try fixing WebFrameImpl::previousHistoryItem to use HistoryController::previousItem() instead of BackForwardList::previousItem()?

Ah.  This does fix the bug, and it looks like it's the right move for the other callers as well (e.g., the equivalent callers in test_shell and DRT).

Note that this requires adding a previousItem() getter to HistoryController, since it only has a private field for it and doesn't currently expose it.

> Likewise, perhaps we should defer the updating of BackForwardList::{current,previous}Item until we commit.  See HistoryController::goToItem, where it assigns those directly.

That seems like a much bigger change, especially since the comment in HistoryController::goToItem says it eagerly updates the BF cursor on purpose.  Do we need to tackle that one here?

I've uploaded a new patch.  The webkit-patch script generated the ChangeLog, but I'm wondering if I'm doing that wrong-- I thought this would have required modifications to two separate ChangeLog files.

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