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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 1 03:59:11 PDT 2013


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





--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-04-01 03:57:23 PST ---
(In reply to comment #0)
> As part of porting uzbl[1] to WebKit2, I've found a number of APIs are missing compared to WebKit1. I was wondering what plans there might be for them and whether they'd be possible again:

Thanks! I'll reply to some of them.

>   - 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

>     * a command to authenticate to a site;

HTTP authentication should just work by default.

>     * external authentication dialog handling (e.g., scripted auth support);

We plan to add API to allow handling HTTP auth request.

>     * custom proxy handling (I'm planning on using domain sockets rather than TCP sockets in the future);

Proxy settings should just work by default.

>   - 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.

>   - access to webkit's scrollbars (uzbl has a scroll command for keybindings);

Scrolling with keys should just work too.

>   - 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.

>   - a call to remove all web databases used by webkit;
>   - web database management (WebKitSecurityOrigin);
>   - access to webkit's spellchecking;

What do you need exactly?

>   - loading arbitrary content into a frame (webkit_web_frame_load_string);

what's the use case for this?

>   - 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

>   - 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);
>   - setting the zoom type (content or text only);

http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitSettings.html#WebKitSettings--zoom-text-only

>   - getting the current page's encoding;

http://www.webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-get-custom-charset

>   - 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

>   - 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,
>       - 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),
>       - enable-display-of-insecure-content (there is only a signal that it happened),
>       - enable-running-of-insecure-content (same as display variant),
>       - enable-scripts,
>       - enable-dom-paste,
>       - auto-shrink-images,
>       - respect-image-orientation,
>       - enable-spatial-navigation,
>       - editing-behavior,
>       - enforce-96-dpi,
>       - minimum-font-size,
>       - minimum-logical-font-size,
>       - enable-accelerated-compositing (is this always true in WebKit2?),
>       - enable-css-shaders,
>       - enable-media-stream,
>     * on WebKitWebInspector:
>       - javascript-profiling-enabled,
>       - timeline-profiling-enabled,
>     * on WebKitWebView:
>       - transparent,
>       - editable.
> 
> 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.

> For further tracking of specific items, creating a new bug is probably preferable (rather than polluting this bug). However, making one bug for each from the start seems overkill if I've missed things and half are just going to be closed right away.

Yes we can use this as a meta bug and open specific bug reports blocking this.

> [1]http://uzbl.org

-- 
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