[Webkit-unassigned] [Bug 113663] Missing APIs in webkit2gtk (compared to webkit1)

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Ben Boeckel <mathstuf at gmail.com>  2013-04-01 09:22:42 PST ---
These comments are getting quite long. Want to open bugs for things that you plan on addressing and then I'll open bugs for those which might need more discussion to convince you that they're needed/nice enough to have? After all the big stuff is done, we can deal with the more nitpicky things.

(In reply to comment #1)
> (In reply to comment #0)
> >   - the SoupSession in inaccessible which was used for:
> 
> This is simply not possible, because the network is in the web process. However, we expose in the UI process API for several network features.
> 
> >     * send events on cookie add/delete so that plugins could filter and persist cookies between instances;
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitCookieManager.html#WebKitCookieManager-changed

So…on every cookie change, we need to iterate over every cookie and compare it to every cookie we had before to make the same events? Since the SoupSession isn't accessible, the following APIs would be satisfactory:

  - cookie-added signal
  - cookie-removed signal
  - add_cookie API
  - remove_cookie API

This would basically get us what we are getting now with access to the SoupSession (except proxy support, see below).

> >     * a command to authenticate to a site;
> 
> HTTP authentication should just work by default.

Sure, but instead of a dialog, a user might have scripted auth to a site which means we need a signal like authentication-requested which can be blocked.

> >     * external authentication dialog handling (e.g., scripted auth support);
> 
> We plan to add API to allow handling HTTP auth request.

Sounds good.

> >     * custom proxy handling (I'm planning on using domain sockets rather than TCP sockets in the future);
> 
> Proxy settings should just work by default.

My plan was to use a per-instance proxy for uzbl to do some things which aren't easy with the WebKit API: setting/changing/removing HTTP headers, host/path based blocking (though policy-decision might be possible for this), caching, implementations of some Mozilla projects (e.g., collusion). Since a user might have 20 instances open, taking up 40 TCP ports might be overkill, so I was going to use UNIX sockets instead. This requires uzbl to be able to set a custom proxy URI and GProxy on the SoupSession to force it to talk over AF_UNIX rather than TCP (see this[1] thread). Plus, I can lock down AF_UNIX sockets to be only accessible by the user running uzbl.

> >   - access to frames. There are a few things this blocks:
> >     * support for issuing JS commands to the currently focused frame (to avoid CORS errors);
> >     * printing the currently focused frame;
> >     * commands manipulating frame focus, listing frames, etc.;
> 
> We don't plan to expose Frames in the API unless there are use cases that justify it.

Because uzbl is modal, being able to swap the current frame focus would be good for sending requests to specific frames (CORS is going to block JS we execute in the top-level frame).

> >   - access to webkit's scrollbars (uzbl has a scroll command for keybindings);
> 
> Scrolling with keys should just work too.

With hjkl? Since uzbl is modal, so space/pgup/pgdown won't work without this unless you're in 'insert' mode. Plus there are behaviors with default keys I dislike (space is better as half-page since PgDn already does full page, but whatever :) ).

> >   - a comparable API to WebKitWebPluginDatabase for:
> >     * refreshing the plugin list;
> >     * toggling specific plugins (and a property in WebKitWebPlugin for whether it is enabled);
> >   - a non-async API for plugin queries;
> 
> Why do you need to do it synchronously? It might take a long time and it would block the main thread.

There's a variable with the list of plugins; it'd be nice to populate it on demand, but I suppose I could make a command to populate these async properties in the background.

> >   - a call to remove all web databases used by webkit;
> >   - web database management (WebKitSecurityOrigin);
> >   - access to webkit's spellchecking;
> 
> What do you need exactly?

WebKit1 had the ability to teach words, get suggestions, etc.

> >   - loading arbitrary content into a frame (webkit_web_frame_load_string);
> 
> what's the use case for this?

WebKit1 had it. Without it, we can only load text/plain and text/html. I'm not married to its fate in WebKit2.

> >   - unsetting security policies for schemes (though an API like WebKit1 with enum flags rather than an array of functions would be better anyways);
> 
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitSecurityManager.html

*Un*setting policies :) . Those APIs only let us set them.

> >   - access to the actual JS context of the page (webkit_web_view_get_javascript_global_context returns an isolated context);

?

> >   - a function to get a WebKitHitTestResult at an arbitrary point on the page (uzbl has support for emulating clicks, so "last hover target" isn't necessarily useful);

This doesn't seem to work with WebKit2. The test you pointed me at simulates mouse moving. In any case, I'm not seeing LINK_HOVER events when doing the click emulation, so we wouldn't be able to just use "last hover target".

> >   - setting the zoom type (content or text only);
> 
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitSettings.html#WebKitSettings--zoom-text-only

Ah, I had named the bindings differently between WebKit1 and WebKit2. Thanks.

> >   - getting the current page's encoding;
> 
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-get-custom-charset