On Sep 8, 2008, at 8:36 AM, Anton V. Tarasov wrote:
> FrameLoader::continueLoadAfterWillSubmitForm(PolicyAction) just
> ignores its PolicyAction param
That's a little bit sloppy, but working as designed.
This client call is sharing the same mechanism with the other client
calls, but unlike t
Darin,
Still there's some more question...
In FrameLoader::continueLoadAfterNavigationPolicy method we have:
if (formState) {
m_client->dispatchWillSubmitForm(&FrameLoader::continueLoadAfterWillSubmitForm,
formState);
} else {
continueLoadAfterWillSubmitForm();
}
Hi Darin,
Thanks a lot for your explanation. My question based on wrong understanding
of the policy check logic. Now it's clear for me what it should be.
Thanks!
Anton.
Darin Adler wrote:
> On Sep 3, 2008, at 4:56 AM, Anton V. Tarasov wrote:
>
>> The method FrameLoader::continueAfterNavigationP
On Sep 3, 2008, at 4:56 AM, Anton V. Tarasov wrote:
> The method FrameLoader::continueAfterNavigationPolicy (the first
> stack) calls m_client->canHandleRequest(request) in its turn in
> order to request an approval from the client.
Yes, there is a client function named canHandleRequest, but
Hello Team,
Let me ask a question on the browsing policy check mechanism in the WebCore.
Comparing these two call stacks:
FrameLoader::continueAfterNavigationPolicy
FrameLoaderClient::dispatchDecidePolicyForNavigationAction
FrameLoader::checkNavigationPolicy
FrameLoader::load
FrameLoader::cont
5 matches
Mail list logo
