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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 1 10:52:53 PDT 2013


--- Comment #6 from Ben Boeckel <mathstuf at gmail.com>  2013-04-01 10:51:05 PST ---
(In reply to comment #5)
> > 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 ha
ve 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 acce
ssible by the user running uzbl.
> A lot of these things (perhaps all?) could be handled more efficiently via a WebExtension.

The API for WebExtensions seems a little bare which is why I skipped it before. Is there an example of an extension that does something like this.

> The proxy approach is kind of funky.

I can't say I disagree, but do you have another suggestion that would work with per-instance proxies? That aren't accessible from users other than the user running uzbl.

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

Currently supported with WebKit1:

  - page-relative: move relative to page size (50% for half page, -25% for up a quarter page);
  - unit-relative: "units" (50 goes down 50 "units" of whatever the scrollbar is reporting);
  - named-location: "begin" and "end" for home/end;
  - absolute-location: 20! moves to location 20 "units" on the scrollbar;
  - relative-location: 20%! moves to 20% of the total scrollbar height.

If you want to add commands for these (all of which except absolute-location have definite uses (relative-location is nice when restoring a page and named-location can probably be turned into 0%! and 100%!).

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

I assume that the enchant instance the webpage uses for edit boxes is beyond the IPC call? For non-webkit-associated spellchecking, the user can just exec hunspell.

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

Makes sense.

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

I'm fine with that.

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

In that case, I'll see if I can come up with other things that would be nice ;) .

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

Sounds reasonable, the WebExtensions just need either better docs or more API to do these things it looks like.

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

The uzbl code will likely need to move over to a threaded architecture to deal with the async calls that are required (and I'm assuming any comm with our WebExtension would need to be async as well).

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