Bug 93002 – [GTK] webkit_dom_document_create_tree_walker impossible to use due to WebKitDOMNodeFilter

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Charles Salvia]

As per http://lists.webkit.org/pipermail/webkit-gtk/2012-August/001186.html, the following bug (incomplete functionality) exists with the WebKitDOMTreeWalker API:

webkit_dom_document_create_tree_walker is not possible to use, because:

1) It requires a non-NULL WebKitDOMNodeFilter pointer

As per the usage of document.createTreeWalker in Javascript, this is a bug because you are allowed to pass "null" for the Filter parameter in Javascript.  In WebKitDOMDocument.cpp, in the function body for webkit_dom_document_create_tree_walker, the line g_return_val_if_fail(filter, 0) should be removed, because WebCore::Document::createTreeWalker() will accept a NULL filter.  The Document::createTreeWalker() function will convert the null raw pointer to a smart pointer, and pass it to a WebCore::Traversal instance.  WebCore::Traversal will then check for a NULL filter in Traversal::acceptNode.  So there is no reason for the GTK layer to check for a NULL with g_return_val_if_fail(filter, 0).

2) The Webkit GTK API does not expose any means to create a WebKitDOMNodeFilter object.  (The header file WebKitDOMNodeFilter.h does not expose a constructor.)

In combination with (1), this second bug makes WebKitDOMTreeWalker impossible to use at all, since the Webkit GTK API exposes no way to instantiate a WebKitDOMNodeFilter instance.  In WebKitDOMNodeFilter.h there needs to be a constructor function exposed, which wraps a WebCore::NodeFilter object.  It's also unclear how the WebKit GTK API handles user-provided Node Filters (which are handled using the virtual function NodeFilterCondition::acceptNode() in WebCore.)  Presumably, a derived class of webCore::NodeFilterCondition would need to be created which just defers to a wrapped C function provided at the Webkit-GTK layer.

[Charles Salvia]

This bug should have been filed under the WebKit Gtk component, rather than HTML DOM.  Sorry about the mistake.

[Carlos Garcia Campos]

(In reply to comment #0)
> As per http://lists.webkit.org/pipermail/webkit-gtk/2012-August/001186.html, the following bug (incomplete functionality) exists with the WebKitDOMTreeWalker API:
> 
> webkit_dom_document_create_tree_walker is not possible to use, because:
> 
> 1) It requires a non-NULL WebKitDOMNodeFilter pointer
> 
> As per the usage of document.createTreeWalker in Javascript, this is a bug because you are allowed to pass "null" for the Filter parameter in Javascript.  In WebKitDOMDocument.cpp, in the function body for webkit_dom_document_create_tree_walker, the line g_return_val_if_fail(filter, 0) should be removed, because WebCore::Document::createTreeWalker() will accept a NULL filter.  The Document::createTreeWalker() function will convert the null raw pointer to a smart pointer, and pass it to a WebCore::Traversal instance.  WebCore::Traversal will then check for a NULL filter in Traversal::acceptNode.  So there is no reason for the GTK layer to check for a NULL with g_return_val_if_fail(filter, 0).

We should add this method to canBeNullParams variable to indicate that the node filter can be NULL.

> 2) The Webkit GTK API does not expose any means to create a WebKitDOMNodeFilter object.  (The header file WebKitDOMNodeFilter.h does not expose a constructor.)
> 
> In combination with (1), this second bug makes WebKitDOMTreeWalker impossible to use at all, since the Webkit GTK API exposes no way to instantiate a WebKitDOMNodeFilter instance.  In WebKitDOMNodeFilter.h there needs to be a constructor function exposed, which wraps a WebCore::NodeFilter object.  It's also unclear how the WebKit GTK API handles user-provided Node Filters (which are handled using the virtual function NodeFilterCondition::acceptNode() in WebCore.)  Presumably, a derived class of webCore::NodeFilterCondition would need to be created which just defers to a wrapped C function provided at the Webkit-GTK layer.

The problem is that WebKitDOMNodeFilter shouldn't be a class but an interface, since the method accept_node needs to be implemented by the user.

[Carlos Garcia Campos]

Created attachment 233223 [details]
Patch

I suspect we have the same problem with XPathNSResolver

[Gustavo Noronha (kov)]

Comment on attachment 233223 [details]
Patch

Nice.

[Carlos Garcia Campos]

Committed r170174: <http://trac.webkit.org/changeset/170174>