3) The API is synchronous, while the underlying implementation in
WebKit2/ChromeClient is asynchronous. So while the engine can do it, our API
forces the application to make a synchronous decision.
It seems to me this assumption is not correct. The appropriate code part
is WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction. It
sends a synchronous message so we need to answer immediately on the UI side:
// Notify the UIProcess.
if
(!webPage->sendSync(Messages::WebPageProxy::DecidePolicyForNavigationAction(m_frame->frameID(),
action->navigationType(), action->modifiers(), action->mouseButton(),
request, listenerID, InjectedBundleUserMessageEncoder(userData.get())),
Messages::WebPageProxy::DecidePolicyForNavigationAction::Reply(receivedPolicyAction,
policyAction, downloadID)))
return;
// We call this synchronously because WebCore cannot gracefully
handle a frame load without a synchronous navigation policy reply.
if (receivedPolicyAction)
m_frame->didReceivePolicyDecision(listenerID,
static_cast<PolicyAction>(policyAction), downloadID);
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
