FrameLoaderClient misses NewWindowAction policy check
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::continueAfterNewWindowPolicy FrameLoaderClient::dispatchDecidePolicyForNewWindowAction FrameLoader::checkNewWindowPolicy FrameLoader::load I found out that the latter actually doesn't check the NewWindowAction policy =( The method FrameLoader::continueAfterNavigationPolicy (the first stack) calls m_client->canHandleRequest(request) in its turn in order to request an approval from the client. However the method FrameLoader::continueAfterNewWindowPolicy (the second stack) does nothing to get an approval. The class FrameLoaderClient misses a method like "canOpenNewWindow" at all... Could you please tell me if I'm wrong (and what is the solution then?) or should I propose a patch. Thank you in advance, Anton.
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
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
Darin, Still there's some more question... In FrameLoader::continueLoadAfterNavigationPolicy method we have: if (formState) { m_client->dispatchWillSubmitForm(&FrameLoader::continueLoadAfterWillSubmitForm, formState); } else { continueLoadAfterWillSubmitForm(); } However, FrameLoader::continueLoadAfterWillSubmitForm(PolicyAction) just ignores its PolicyAction param (assigned to PolicyUse by default). So, in case of submit (when the formState above is not null) it seems like the client can cancel loading only by means of the following call: m_client->dispatchDecidePolicyForNavigationAction made earlier on the stack. Then, what is the purpose of continueLoadAfterWillSubmitForm(PolicyAction)? Could you please clarify it? Thank you, 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
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 the others it's designed only to delay the submission of the form, and does not allow cancellation; there's no real "policy" here. This is something we could change and refine, but as I say it's working the way it was intended.
Then, what is the purpose [of the dispatchWillSubmitForm client function]?
Safari, for example, uses this client function to pick up form values for later use in form auto-fill. -- Darin
participants (2)
-
Anton V. Tarasov
-
Darin Adler