[webkit-gtk] webextensions, iframes and main gui process

[Gaute Hope]

Hi,

I am using WebKit2 with webextensions (WE) for parts of my GTK gui. I am 
in the process of porting from WebKit1 to WebKit2 and the new 
webextensions design [0].

The main GUI process adds the webkit widget to my GUI, and initializes 
the webextension. The main GUI process and the WE-process communicate 
using UNIX domain sockets and Google protobuf. The necessary socket 
address is passed on WE-initialization.

The WE builds the page using DOM manipulation on top of a skeleton page. 
The data which the WE is using for building the page is passed from the 
main GUI process. Both user-input (keyboard, mouse GTK events) on the 
main GUI, as well as outside events (timer-based) can cause the page to 
be changed. These are passed from the main GUI process as messages to 
the WE-process. The state of the rendered page (scroll, visible 
elements) is passed back to the main GUI and is necessary for the 
processing of the events.

A reader-thread on the WE-extensions listens for messages from the main 
GUI thread. Whenever the DOM tree is changed this is done on the main GTK 
thread on the WE.

In order to make sure that no race-conditions happen between the events 
(e.g. if the state is in the process of being changed on the page from 
the WE) the main GUI process locks the output stream (to safeguard 
against concurrent writes on the pipe) and more importantly needs to 
wait for the WE-GUI thread to finish the DOM manipulation. This is done 
by waiting for an acknowledgement message from the WE containing the 
updated state. 

Now for the twist. 

I wish to display parts of the data in IFRAME's to completely isolate it 
from the rest of the page and other parts of the data. However, adding 
an IFRAME and setting its src to something (data:text/html,... in my 
case) causes a request to be made. This request needs to be handled on 
the main GUI thread. Additionally, the WE-GUI blocks untill the request 
has been processed. Naturally, the acknowledgment message is not 
returned untill it is complete. But this causes the main GUI to block 
and not process the request. So we have a deadlock. It is also not 
enough to just make this request async, because if I send anther message 
to the WE which waits for an acknowledgement racing against the IFRAME 
handling this will also cause the main GUI to likely be blocked before 
the IFRAME-request has been processed. This is not dependent on me 
having a custom callback handler for the decision-policy.

Because of this request-callback-block from the IFRAME it becomes fairly 
complicated for me to ensure against race-conditions from main GUI 
events. Because anything that causes the main GUI to wait for a 
response back from the WE could block the IFRAME request and cause a 
deadlock.

Do you have any suggestions for how I could design or circumvent this?

Note that even if I guard against user-input untill the IFRAME has been 
processed timer based events could still happen.

Also, I could not find any documentation on how the requests on the 
IFRAME work. Or that it would make this on the main GUI. If this IFRAME 
request was non-blocking on the WE-GUI thread I believe my problems 
would be solved. Is this the case for image set src as well?

Best regards, 
Gaute

[0] https://github.com/astroidmail/astroid/pull/455

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20180621/3da6ecc7/attachment.bin>