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.robin...@gmail.com
<mailto:martin.james.robin...@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@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
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
