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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 1 09:24:30 PDT 2013


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

>From the WebKit1 API, "custom-charset" could be different than "current-encoding". Is this no longer true?

> >   - get/set the total application cache maximum size;
> 
> Cache sizes are calculated automatically depending on the cache model set:
> 
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html#webkit-web-context-set-cache-model

Sounds good.

> >   - a comparable API to WebKitViewportAttributes;
> >   - access to the DOM of a page/frame;
> 
> http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitWebPage.html#webkit-web-page-get-dom-document
> 
> >   - the following properties:
> >     * on WebKitWebSettings:
> >       - auto-resize-window,

This behavior is annoying and it would be nice to be able to turn it off.

> >       - enable-universal-access-from-file-uris (ignorable if unsetting security policies is possible),
> >       - enable-file-access-from-file-uris (ignorable if unsetting security policies is possible),

If functions to unset policies on schemes is added, these are unrequired, otherwise once you lock down the file scheme, you can't unlock it.

> >       - enable-display-of-insecure-content (there is only a signal that it happened),
> >       - enable-running-of-insecure-content (same as display variant),

I suppose the policies also take care of these.

> >       - enable-scripts,

It would be nice to have really crude NoScript support.

> >       - enable-dom-paste,

Is javascript-can-access-clipboard a superset of this? If so, I can live with just that.

> >       - auto-shrink-images,
> >       - respect-image-orientation,

They exist in WebKit1 and users might want these behaviors.

> >       - enable-spatial-navigation,

I suppose this might be someone's preferred link navigation method… Personally, I just use a link labeller.

> >       - editing-behavior,

Maybe someone likes editing behavior other than "native"?

> >       - enforce-96-dpi,

This is under "hack" anyways, so this can disappear without qualms.

> >       - minimum-font-size,
> >       - minimum-logical-font-size,

WebKit2 is showing much smaller fonts than WebKit1 with the same settings; I'll have to do some investigating as to whether it's just a WebKit1 -> WebKit2 change or these variables are helping WebKit1.

> >       - enable-accelerated-compositing (is this always true in WebKit2?),
> >       - enable-css-shaders,
> >       - enable-media-stream,

I'm guessing these are always enabled in WebKit2. I imagine they were optional because they were unstable. I'm fine with living without these.

> >     * on WebKitWebInspector:
> >       - javascript-profiling-enabled,
> >       - timeline-profiling-enabled,

The timeline-profiling-enabled property was already deprecated, but it'd be nice to be able to control the inspector without a mouse (to click the buttons for these).

> >     * on WebKitWebView:
> >       - transparent,
> >       - editable.

These behaviors are really nice to have (I use editable at least).

> > If I'm missing something in WebKit2 that does the same thing, I may have missed it. I've been over both sets of docs a few times and still find new things every now and then. If there is no plans to support a feature, the only ones which are 100% required for uzbl to work is access to the scrollbars, SoupSession, and page's JavaScript context.
> 
> We need use cases for those, to understand the problems.

I don't really have hard use cases for all of them. A few are just "huh, where'd that go?" when moving over to WebKit2. Uzbl is basically a browser which tries to expose all WebKit settings to the user. In the end, it'd be nice to have all of these so that I can remove a lot of #ifndef USE_WEBKIT2 blocks from the code (or at least have #else sections for them).

[1]https://mail.gnome.org/archives/libsoup-list/2013-January/msg00001.html

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


More information about the webkit-unassigned mailing list