Timeout when calling dom method in WebExtension via dbus

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Marcel Tiede]

Hi,

I created a vala GTK3 Application using a WebView which loads a WebExtension. Now I try to call a method from the WebExtension via dbus originating from the GTK Application. The WebExtension should click via the DOM API on the loaded HTML page. Calling the click method via a dbus-inspector or separate programs works ok. But calling the click from the GTK-Application via dbus results in a timeout and afterwards the click is performed.

Probably this problem is related to webkitgtk / webkit, because by removing the actual clicking command the timeout is gone. In the Attachments you can find a sample including the valac commands.

In the File Browser.vala are two path entries which must be adjusted to the system. For my testing I used Version 2.4.3 from webkitgtk.

[Marcel Tiede]

Created attachment 234464 [details]
Example Files

[Marcel Tiede]

Errormessage translated: Timeout reached (g-io-error-quark, 24)

[Jiří Janoušek]

Hi Marcel,

I've modified your code to perform DOM manipulation in an idle callback and it does work :-)

--- dbuswebkit(0)/WebExtension.vala	2014-06-30 21:35:54.000000000 +0200
+++ dbuswebkit/WebExtension.vala	2014-07-10 22:50:22.234275010 +0200
@@ -69,11 +69,15 @@
     
         public void ClickFAIL() {
             stdout.printf("Controler:ClickFAIL1\n");
+            Idle.add(() => {
+                DOMElement element = mControler.mDom.get_element_by_id("test");
+                ((DOMHTMLElement)element).click();
+                
             
-            DOMElement element = mControler.mDom.get_element_by_id("test");
-            ((DOMHTMLElement)element).click();
+                stdout.printf("Controler:ClickFAIL2\n");
+                return false;
+            });
             
-            stdout.printf("Controler:ClickFAIL2\n");
         }
         
         public void ClickOK() {

[Marcel Tiede]

Your codes fixes the Problem. Thank you Jiří.

If this behaviour is expected from Webkit point of view this bug is solved.

[Marcel Tiede]

Fixed for me.