Bug 93002 - [GTK] webkit_dom_document_create_tree_walker impossible to use due to WebKitDOMNodeFilter
Summary: [GTK] webkit_dom_document_create_tree_walker impossible to use due to WebKitD...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 133724
  Show dependency treegraph
 
Reported: 2012-08-02 09:34 PDT by Charles Salvia
Modified: 2014-06-19 23:44 PDT (History)
10 users (show)

See Also:


Attachments
Patch (39.30 KB, patch)
2014-06-17 02:41 PDT, Carlos Garcia Campos
gns: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Salvia 2012-08-02 09:34:12 PDT
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.
Comment 1 Charles Salvia 2012-08-02 09:39:29 PDT
This bug should have been filed under the WebKit Gtk component, rather than HTML DOM.  Sorry about the mistake.
Comment 2 Carlos Garcia Campos 2014-06-16 05:40:53 PDT
(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.
Comment 3 Carlos Garcia Campos 2014-06-17 02:41:20 PDT
Created attachment 233223 [details]
Patch

I suspect we have the same problem with XPathNSResolver
Comment 4 Gustavo Noronha (kov) 2014-06-19 13:34:19 PDT
Comment on attachment 233223 [details]
Patch

Nice.
Comment 5 Carlos Garcia Campos 2014-06-19 23:44:55 PDT
Committed r170174: <http://trac.webkit.org/changeset/170174>