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::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 > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
