[Webkit-unassigned] [Bug 48812] FrameLoader::checkLoadCompleteForThisFrame uses wrong history item

[bugzilla-daemon at webkit.org]

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





--- Comment #21 from Charles Reis <creis at chromium.org>  2010-11-10 14:14:26 PST ---
(In reply to comment #20)
> (From update of attachment 73449 [details])
> A general note: any design that involves both HistoryItem and ResourceRequest seems suspicious. These are pretty distant layers to talk to each other.

That's fair.  Do you have a suggestion for how to tell whether the canceled request in pdl (which is a DocumentLoader) corresponds to page->backForward()->currentItem() (which is a HistoryItem)?  Without that, we'll continue to corrupt HistoryItems if a new navigation has already begun.  Or conversely, how to distinguish if the request was canceled due to a new navigation or not?

Other options that I see: we could associate either the DocumentLoader or its NavigationAction with the HistoryItem.  It might reasonable to add a HistoryItem field to NavigationAction, so that we can tell which HistoryItem triggered it.  That'd fix this bug without touching ResourceRequest.

> 
> Requests already have identifiers, see e.g. FrameLoaderClient::assignIdentifierToInitialRequest(). Adding another "ID" would be terribly confusing.

Unfortunately, that identifier doesn't help-- there's no way to query which identifier is assigned to a given request, so we can't use it to compare requests.  Additionally, the assignIdentifierToInitialRequest call currently does nothing in either Chrome (RenderView) or test_shell (WebViewDelegate).


> 
> And of course m_id won't persist a Mac Objective-C API delegate call. See <http://trac.webkit.org/browser/trunk/WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm#L387> - the request is re-created from scratch after a client has a chance to modify it.

Glad you pointed that out.  The NavigationAction approach should avoid that, by not depending on the ResourceRequest at all.

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