[webkit-gtk] Webkit GTK Release 2 - basically unusable for us

Niranjan Rao nhrdls at gmail.com
Thu May 2 12:19:21 PDT 2013

On 05/02/2013 12:57 AM, Sergio Villar Senin wrote:
> En 02/05/13 02:59, Eric Gregory escribiu:
>> On Wed, May 1, 2013 at 5:41 PM, Martin Robinson
>> <martin.james.robinson at gmail.com
>> <mailto:martin.james.robinson at gmail.com>> wrote:
>>      A WebPage corresponds to a WebView, but on the WebProcess side. The C
>>      API exposes frames, but we have not exposed them in the GObject API
>>      because we aren't sure if they will continue to be part of the
>>      internal UIProcess API. That decision is really up to the Apple
>>      developers -- who have said in the past they were thinking of ditching
>>      them entirely.
>>      I think what Niranjan is trying to accomplish should be possible with
>>      a combination of user scripts (which can be injected into all frames)
>>      and the injection of native JavaScript methods into the DOM. We hope
>>      to add both of these things to a future release.
>> Wait, are you saying the C-based DOM API *is* going away?
> This was already explained during the 2.x development process. In the
> new multiprocess architecture, the DOM tree lives in the WebProcess
> while your application is the UIProcess. Synchronous communication
> between both (as DOM bindings will require) is not (generally) allowed
> between these two processes because they must not block. Apple for
> example decided to reimplement for Safari all the use cases where they
> used their DOM bindings.
> Said that, it's still possible to access the DOM :-). The solution is
> the new WebExtensions API developed for 2.x series. You'd basically have
> to define a extension (kind of a plugin) that will be loaded by the
> WebProcess (so it can directly access the DOM) and that could talk back
> to your application using D-Bus or whatever method you like. Check for
> example ephy-web-extension.c [1] in the epiphany source code which
> implements the "save passwords from form" feature among others.
> BR
> [1]
> https://git.gnome.org/browse/epiphany/tree/embed/web-extension/ephy-web-extension.c
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk

Could you please point me to email and/or other documents where it 
explains this. I am relatively new comer on this list and not sure if it 
was discussed on this list or not.

I did look at epiphany code, but its not clear to me whether 
WebkitWebPage stands for a frame or master document. That distinction is 
very important to reach to right element.

I chatted with mrobinson yesterday (thank you mrobinson) and he did 
explain some more things which clarified my current problem a bit more.  
However issue still remains that moving from 1.* to 2.* is going to be 
lot more complicated.

My problem is multi fold. I need to carry data to and forth between view 
and application. I could do that using dom access and hacky non pefect 
way of script alerts or listening for other events. Now its going to be 
complicated for view to inform app that something interesting has happened.

Imagine phone gap type applications where data flows back and forth 
between device and view. It's going to be difficult to develop these 
kind of applications on 2.* in its current state. For example I have 
python application that uses script-alert signal to pass data between 
web view and app since  DOM events are not exposed in python. There 
might be equivalent (I haven't checked or found it yet) but its no 
longer on web view as there is a script-dialog signal which has 
different functionality. For many desktop applications this 
functionality is very useful or required- one example is welcome screen 
of eclipse where a button click has to be notified to core engine to 
open another dialog or screen or whatever way it chooses to act on it.

In short, web view is more like a browser than a component for desktop 
application now where you can interact and pass data to each other.



More information about the webkit-gtk mailing list