Summary: | Restore FrameLoader::policyDocumentLoader to fix the Chromium build | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Darin Fisher (:fishd, Google) <fishd> | ||||
Component: | Page Loading | Assignee: | Darin Fisher (:fishd, Google) <fishd> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | darin | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Darin Fisher (:fishd, Google)
2009-04-03 09:40:51 PDT
Created attachment 29229 [details]
v1 patch
> This is important since the FrameLoaderClient may have subclassed
> DocumentLoader to provide additional state
Clarification: What I mean is that from FrameLoaderClient::createDocumentLoader, the FrameLoaderClient implementation can allocate a class that subclasses DocumentLoader. Then from other FrameLoaderClient methods, that subclass is exposed via a down cast from DocumentLoader.
Comment on attachment 29229 [details]
v1 patch
It would be good to know why this is needed. I think it’s likely a mistake.
r=me on bringing it back
(In reply to comment #0) > We found that there are some FrameLoaderClient callbacks that occur when the > current DocumentLoader is m_policyDocumentLoader, and without an accessor to > that, it is not possible from FrameLoaderClient to access the DocumentLoader. We should consider adding the DocumentLoader as an argument to those functions to solve the problem. > We should consider adding the DocumentLoader as an argument to those functions > to solve the problem. That sounds like a good idea. The FrameLoaderClient method in question is dispatchDecidePolicyForNavigationAction. Landed as: http://trac.webkit.org/changeset/42202 The key issue is that the policyDocumentLoader doesn't become provisional until after dispatchDecidePolicyForNavigationAction OKs the navigation. |