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

Mon Nov 8 17:10:10 PST 2010

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

Charles Reis <creis at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |

--- Comment #17 from Charles Reis <creis at chromium.org>  2010-11-08 17:10:09 PST ---
(In reply to comment #16)
> Ugh.  It is not uncommon for code in Chromium (e.g., navigation_controller.cc) to be working against you in cases like this because it was trying to compensate for some bug in WebKit (such as the one you fixed here).

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)

I'm wary about changing the behavior of HistoryController itself, but that does seem like odd behavior.  Darin, do you understand what's going on there?  Is it better to change to having a new WebFrameImpl::lastCommittedHistoryItem() method (as in the earlier patch here), or to try to avoid setting m_previousItem to null?

Either way, this has led to buggy navigation behavior in Chrome, so we may want to revert this patch.

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