[webkit-gtk] WK2: Adapting the Policy Decision Framework for Geolocation

[Mario Sanchez Prada]

Hi all,

A couple of days ago I started working in the implementation of
geolocation support for WebKit2GTK+ (see [1]), and came to the
conclusion that the Policy decision we have already in place could be
useful for implementing the decision making mechanism that we need here.

Such a mechanism would work like this:

 1. A Website tries to use the Geolocation API [2] for the first time.
 2. WebKit requests permission to the user through the 
    GeolocationClient interface [3], implemented in the WebProcess, 
    which ends up sending a message to the UIProcess.
 3. In the UIProcess decidePolicyForGeolocationPermissionRequest() is 
    invoked for the UI Client (WebKitWebUIClient, for gtk)
 4. A signal would be emitted from the WebView with an special object 
    attached, so the application could make a decision by invoking some 
    methods like use()/ignore, allow()/deny, or the like...

So, it turns out that the interface provided by WebKitPolicyDecision (so
far used only by the policy client) is currently like this:

 void webkit_policy_decision_use      (WebKitPolicyDecision *decision);
 void webkit_policy_decision_ignore   (WebKitPolicyDecision *decision);
 void webkit_policy_decision_download (WebKitPolicyDecision *decision);

...which certainly looks like something we could use for geolocation as
well, if we ignore the download() operation (that we would not use).
This would allow us to treat permission requests for geolocation as yet
another policy decision to be made from the point of view of apps using
the API, regardless of the fact that internally this kind of requests
and the ones already covered by the policy client ('navigation' and
'response' policy decisions) are actually different and work with
different interfaces in the WebProcess and WebCore.

However, I'm afraid the current implementation of PolicyDecision has
some problems for reusing that stuff _cleanly_ for geolocation. My
biggest concerns are:

 - I understand this 'use', 'ignore' and 'downlad' actions just mimic
   the C API which, at the end, is mapping the cases in WebCore's
   PolicyAction. And it's fine as long as we only use this from the
   Policy Client. But it's weird to have a 'download' operation
   available for the object emitted with the 'decide-policy' signal when
   making a decision about geolocation.

 - Current implementation of WebKitPolicyDecision (see .cpp file) 
   assumes there's a listener, of type WKFramePolicyListenerRef, where 
   the 'use', 'ignore' and 'download' operations would be delegated 
   when making a decision from the app. For the case of geolocation,
   though, this "listener" would not be an object of that type but of
   type WKGeolocationPermissionRequestRef, which provides two methods to
   allow making a decision: allow() and deny().

So I'm thinking of slightly changing the Policy Decision design to fit
this geolocation stuff, and I've thought of two possibilities so far.
I've attached some quick diagrams I made with Dia to better explain
what's in my head at this moment.

* Option 1 (geolocationWK2-option1.png):
----------------------------------------

 - Rename WebKitPolicyDecision to WebKitFramePolicyDecision

 - Rename the use() and ignore() methods to accept() and reject(), 
   which are more general, even if internal implementation is the same,
   in terms of WKFramePolicyListenerRef's use() and ignore() methods.

 - Create a new abstract class (WebKitPolicyDecision) with two abstract 
   methods, accept() and reject(). WebKitFramePolicyDecision would be a 
   subclass of this one, obviously.

 - Create a new class WebKitGeolocationPolicyDecision, implementing 
   accept() and reject() in terms of WKGeolocationPermissionRequestRef's
   allow() and deny() methods.


* Option 1 (geolocationWK2-option2.png):
----------------------------------------

 - Create a new abstract class WebKitPolicyListener, with use(), 
   ignore() and download() methods.

 - Create two subclasses of WebKitPolicyListener, one for "frame policy 
   decisions" and other for "geolocation policy decisions". 

 - WebKitFramePolicyDecisionListener would implement use(), ignore() 
   and download() in terms of WKFramePolicyListenerRef's methods.

 - WebKitGeolocationPolicyDecisionListener would implement use() and 
   ignore() in terms of WKGeolocationPermissionRequestRef's methods, and
   would simply leave empty the implementation of download()

 - We'd replace the WebKitPolicyDecision's attribute 'listener', of type
   WKFramePolicyListenerRef, with other of type WebKitPolicyListener, 
   which would do the right thing in each case.


So far, I think the cleanest approach is Option 1, since we do not have
strange "artifacts" like that empty implementation of download() for the
case of geolocation permission requests, and also because I think the
accept/reject idiom is more correct if we think in general of making a
policy decision, forgetting about the implementation details.

Still, I'm aware this option would imply changing how the API works so
far (WebKitPolicyDecision would become a different thing) and so it's
perhaps not so trivial to go ahead with it, so that's why I'm asking.

I'm of course open to any other suggestion you might have :-)

For the time being, I will keep working having Option 1 in mind.

Thanks,
Mario

[1]https://trac.webkit.org/wiki/WebKitGTK/WebKit2Roadmap
[2]http://www.w3.org/TR/geolocation-API/
[3]http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/page/GeolocationClient.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geolocationWK2-option2.png
Type: image/png
Size: 9287 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120330/a4ebda55/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geolocationWK2-option1.png
Type: image/png
Size: 8564 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120330/a4ebda55/attachment-0003.png>