2018-06-21 13:47:01 UTC
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 .
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
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
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?