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
pgpHoxgxJyKYV.pgp
Description: PGP signature
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
