Bug 181790 – [WPE][GTK] Documentation should warn that our APIs are not threadsafe

• Status: NEW
• Component: WebKitGTK

[Gaute Hope]

Created attachment 331607 [details]
HTML file

While porting some WebKit1 code to WebKit2 using a web-extension to access the DOM tree I am unable to get DOM-objectes (DIV's) document_element_by_id() or element_query_selector() on the same HTML that previously worked with WebKit1. However, by displaying get_body()->get_inner_html() the sources is there (this is all done after the load signals). Also, traversing the tree using e.g.:

    WebKitDOMElement * en;

    WebKitDOMHTMLCollection * es = webkit_dom_element_get_children (WEBKIT_DOM_ELEMENT(b));

    for (unsigned int i = 0; i < webkit_dom_html_collection_get_length (es); i++) {
      WebKitDOMNode * n = webkit_dom_html_collection_item (es, i);

      en = WEBKIT_DOM_ELEMENT (n);

      if (ustring(webkit_dom_element_get_id (en)) == id) break;

      g_object_unref (n);
      en = NULL;
    }

    g_object_unref (es);
    g_object_unref (b);

    return en;

I can find the element. I also have problems using the element_query_selector(), which is unable to find the element. I have not been able to workaround this using something like:

    webkit_dom_element_webkit_matches_selector (WEBKIT_DOM_ELEMENT(n), selector.c_str (), &gerr)

Any ideas on what could be wrong?

HTML is attached.

[Gaute Hope]

I was made aware that I need to access / modify the DOM tree from the main thread of the web extension. I have not done that in this case.

(P.S. It would be nice with a note about this requirement on the WebExtensions page).

[Michael Catanzaro]

(In reply to Gaute Hope from comment #1)
> I was made aware that I need to access / modify the DOM tree from the main
> thread of the web extension. I have not done that in this case.
> 
> (P.S. It would be nice with a note about this requirement on the
> WebExtensions page).

Hm, this is a rule that applies to almost all GLib-style APIs, not just the web extension and not even just WebKit. You can't use any of the UI process APIs on a secondary thread either, for example, nor any GTK+ APIs, and as a rule GObjects may only be used on the thread they were created on.

Still, you're *far* from the first person to make this mistake, so clearly we do need to warn about it somewhere. None of the existing pages in the documentation seem like a very good place, though. We should add some introduction or overview page instead.

[Gaute Hope]

(In reply to Michael Catanzaro from comment #2)
> (In reply to Gaute Hope from comment #1)
> > I was made aware that I need to access / modify the DOM tree from the main
> > thread of the web extension. I have not done that in this case.
> > 
> > (P.S. It would be nice with a note about this requirement on the
> > WebExtensions page).
> 
> Hm, this is a rule that applies to almost all GLib-style APIs, not just the
> web extension and not even just WebKit. You can't use any of the UI process
> APIs on a secondary thread either, for example, nor any GTK+ APIs, and as a
> rule GObjects may only be used on the thread they were created on.
> 
> Still, you're *far* from the first person to make this mistake, so clearly
> we do need to warn about it somewhere. None of the existing pages in the
> documentation seem like a very good place, though. We should add some
> introduction or overview page instead.

I don't doubt it - but it was a quick assumption to make given the dual-process nature of webextensions. I would have appreciated a link on the WebKitWebExtensions page: https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebExtension.html

[Gaute Hope]

Can confirm that this was caused by not accessing DOM from main thread.