[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


Martin Robinson <mrobinson at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrobinson at webkit.org




--- Comment #5 from Martin Robinson <mrobinson at webkit.org>  2013-04-01 10:15:52 PST ---

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

A lot of these things (perhaps all?) could be handled more efficiently via a WebExtension. The proxy approach is kind of funky.

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

This could probably be accomplished with execute_comamnd('MoveDown') or some translation of key events.

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

This API was there because of limitations in the context menu. It was difficult to combine the items from WebCore with custom items. That's a lot easier now, so we don't really need the API. You can always talk directly to enchant though.

> > >       - editing-behavior,
> 
> Maybe someone likes editing behavior other than "native"?

I exposed this setting originally and regret it. Editing behavior should just follow the system convention. Note that WebKit still obeys the user's key bindings.

> 
> > >       - enforce-96-dpi,
> 
> This is under "hack" anyways, so this can disappear without qualms.

As Carlos said, font sizes are now in pixels instead of points, so this setting is now meaningless. :)

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

Accelerated compositing is always on depending on whether your system supports it. I'm not sure if we're going to expose many settings for basic web platform features, since there isn't a clear demarcation of where we should stop.

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

It's important that the web inspector is accessible and can be controlled without a mouse. Perhaps we can ensure that's possible without exposing new settings.

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

To access the page's JavaScript context and SoupSession you'll need to create a WebExtension. This is something inherent in the design of WebKit2, so I don't think we'll be able to change it. Even for the SoupSession, it's likely that we'll never *really* expose it since networking is moving to another process entirely.

Thanks for making this list. Hopefully we can work together to solve the missing features by either adding them or improving the uzbl code to the point that they are no longer necessary.

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