[webkit-dev] FrameLoaderClient misses NewWindowAction policy check

Anton V. Tarasov Anton.Tarasov at Sun.COM
Mon Sep 8 04:33:06 PDT 2008

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.


Darin Adler wrote:
> 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 that call is 
> not requesting the navigation policy. That's a separate client function 
> and it's not about navigation policy. It's only called if the navigation 
> policy named PolicyUse is specified.
> The navigation policy comes from the value passed by the client's 
> m_client->dispatchDecidePolicyForNavigationAction function when it calls 
> the FramePolicyFunction. The code that respects the policy is the switch 
> statement in the continueAfterNavigationPolicy function.
>> However the method FrameLoader::continueAfterNewWindowPolicy (the 
>> second stack) does nothing to get an approval. The class 
>> FrameLoaderClient misses a method like "canOpenNewWindow" at all.
> As in the case of navigation policy, the new window policy comes from 
> the value the client passes back when it calls the FramePolicyFunction 
> passed to m_client->dispatchDecidePolicyForNewWindowAction, which is 
> respected by the switch statement in the continueAfterNewWindowPolicy 
> function.
> You may have a legitimate question here or maybe even a bug, but it's 
> incorrect to call the canHandleRequest function the policy check, so I 
> think you need to at least re-word your question to clarify what you're 
> asking.
> The client function that performs the new window policy check is 
> dispatchDecidePolicyForNewWindowAction.
>     -- Darin

More information about the webkit-dev mailing list