[webkit-gtk] Confusion about web extensions

[Carlos Garcia Campos]

El jue, 19-12-2013 a las 12:43 -0800, Niranjan Rao escribió:
> Greetings,
> 
> Trying my best to understand concept of web extensions and processes. I 
> am mostly following blog entry by Carlos Garcia Campo at 
> http://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/ 
> and example he pointed from epiphany browser at 
> https://git.gnome.org/browse/epiphany/tree/embed/web-extension/ephy-web-extension.c
> 
> 1. The concept process separation - are these actually separate 
> processes with different process ids?

Yes.

> 2. Web extensions - do extensions get any initialization information 
> from parent process. If I want to follow epiphany example which opens a 
> bus, how does it work with multiple epiphany processes? I suppose I can 
> setup environment variable like the example does when root process 
> starts. Is this the recommended way.

It's a way for now, but we are working on improving that, so that you
can pass any initialization information from the UI process to the web
extension, see bug https://bugs.webkit.org/show_bug.cgi?id=125990

In epiphany we use the UI process pid (passed in an env vasriable) in
the D-Bus service name to avoid the problem of multiple ephy processes
that you mention. This approach will not work when multiple web
processes are supported. We will need to use different unique ids in
such case.

> 3. Can extension call webkit_web_view_load_uri  or similar method that 
> will cause view to navigate?

You can't use UI process API from the web process. There's currently no
API in the Web Extensions to load a page, that's supposed to happen in
the UI process.

> 4. What happens when a new tab is opened? Does plugin gets loaded again? 
> My guess is yes since it will be one more process.

No, it's not, because we use a single web process for all the tabs. Once
multiple web processes are supported, a new process will be spawned and
the web extensions will be loaded again for every web process. 

> Typical work flow example in our case is  as follows. There will be 
> multiple processes at same time - visiting various sites with different 
> sessions. I am just trying to figure out how it fits in new paradigm.

It depends on what you mean by multiple processes, multiple UI
processes? or multiple web processes? If you are using multiple UI
processes, there will be a web process for every UI process. Multiple
web processes for a single UI process is not supported yet. And
depending on what you want, you might want to use multiple web processes
for a single UI process but using different web contexts (which is also
currently unsupported)

> A Driver code starts UI which displays webkit window
> Load requested page.
> Check for existence/value of some element using DOM access code.
> Driver decides what needs to be done - click something, visit different 
> page etc.
> 
>  From drivers perspective some of the interesting methods are in one 
> process example webkit_web_view_load_uri  and other goodies. But 
> information it needs to make decisions (that is DOM access) are in 
> another process and it needs to communicate using some sort of IPC 
> mechanism.  I can move most of my driver code to extension side to 
> reduce complications of IPC. At this moment it looks like only thing it 
> needs is ability to navigate to given location.

Is your code available somewhere? How is it currently working? using
WebKit1? 

> Is my understanding correct so far?

Yes, the idea is to move all the logic that uses DOM to make a decision
to the web extension code and send the decision back to the UI process
using D-Bus or any other IPC mechanism.

> Regards,
> 
> Niranjan

Regards, 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20131225/2972f8a3/attachment.sig>