[Webkit-unassigned] [Bug 69870] [Chromium] Empty API for web intents

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=69870





--- Comment #6 from Greg Billock <gbillock at google.com>  2011-11-10 11:16:26 PST ---
(From update of attachment 114381)
View in context: https://bugs.webkit.org/attachment.cgi?id=114381&action=review

>> Source/WebKit/chromium/public/WebIntentsController.h:42
>> +    WEBKIT_EXPORT void webIntentReply(ReplyType, const WebString&, int);
> 
> this looks like it should just be a method on WebFrame.  it should probably have a name that mirrors startActivity, like didCompleteActivity.  For bonus points, the name should really say something about intents.

My goal was to put the dispatch code into the WebCore controller object. Do you think it is preferable to dispatch in the embedder code? I was copying at the way the other notifications processes work (i.e. geolocation notices), which are passed through to controller objects in WebCore.

>> Source/WebKit/chromium/public/WebViewClient.h:323
>> +    virtual void registerIntentHandler(const WebString& action,
> 
> it seems like the request to register an intent handler should be relative to the WebFrame so that the embedder can tell what origin is requesting the intent handler.
> 
> it would probably be good to bundle up these request parameters into a separate structure.

That makes sense. Something to consider alongside this, though: the registerProtocolHandler call is on WebViewClient. Do you think that's misplaced? One comes from a tag and one from a navigator call. But startActivity is on the navigator object as well. I agree knowing the origin is important, but we could pass this along instead of using the FrameLoaderClient->WebFrameClient pathway. Do you think that's preferable? There are a few WebFrameClient-style "method(WebFrame*, args) methods in WebViewClient, so this wouldn't be the first...

>> Source/WebKit/chromium/public/WebViewClient.h:330
>> +    virtual void startActivity(const WebString& action,
> 
> it seems like activities are started by script in the context of a document.  therefore this should also be a WebFrame-relative method (i.e., it should be declared on WebFrameClient).  perhaps the parameters should be bottled up into a WebIntent structure (or some other structure)?
> 
> what is the intentId?  is that supposed to be passed back to WebKit as the third parameter to webIntentReply?  is there really any need for an intent identifier?  can there be multiple overlapping startActivity calls made by a single script context?

I currently have the intent ID as a way to make a positive connection between the invocation and the registered javascript callback. If the policy is that we'll only allow one intent in process, then there's no need for it; we'll just have one registered callback. I didn't want to hardcode that policy at this point, though.

If we have a structure for the intent data, it'll be moot, as the intent ID will ride along there. In my webkit implementation patch I do currently have a WebCore Intent object that would be natural wrapped analog for this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.