Moving NodeIterators in NodeFilters

I'm wondering what should happen if a NodeFilter causes its NodeIterator
(or TreeWalker) to move.

Lets say we have 4 nodes (call then node1, node2...) that are being
iterated over, and a filter that always accepts but calls
NodeIterator.nextNode when called (for the first time) with node2.
There are a number of possible outcomes, depending on how we deal with
filters:

1) Remember the state which we will move to if the filter accepts our
node, and use this state when the filter returns (giving node1, node2,
node3, node4 and the filter got node2);

2) Store our candidate node in the iterator, return the candidate that
was stored in the iterator if the filter accepts it (giving node1,
node3, node4 and the filter got node3);

3) Update the iterator before calling the filter, then return the node
we called the filter with if it was accepted (giving node1, node2, node4
and the filter got node3);

4) Raise an exception when the iterator is called recursively;

5) Return null after the iterator has been called recursively
(presumably in an invalid state);

6) Crash.

I think option 3 is the most sensible of the first 3 - it returns each
node once, however my preference would be option 4 - its easy to
implement and authors would spot their mistake (I'm assuming it was a
mistake).

Test page is at http://ado.is-a-geek.net/www-dom/nodefilter.html

Opera uses option 4
Chrome and Safari use option 5
Firefox uses option 6 (bug #559526)

Should this be clarified in the spec if an agreement on what to do can
be reached?

-- 
Andrew Oakley

Received on Thursday, 15 April 2010 12:10:45 UTC