[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.
Thanks,
Niranjan
More information about the webkit-gtk
mailing list