RESOLVED FIXED 149493
TreeWalker.previousSibling() / nextSibling() does not behave according to the specification
https://bugs.webkit.org/show_bug.cgi?id=149493
Summary TreeWalker.previousSibling() / nextSibling() does not behave according to th...
Chris Dumez
Reported 2015-09-22 23:37:27 PDT
TreeWalker.previousSibling() / nextSibling() does not behave according to the specification: - https://dom.spec.whatwg.org/#dom-treewalker-nextsibling - https://dom.spec.whatwg.org/#dom-treewalker-previoussibling - https://dom.spec.whatwg.org/#concept-traverse-siblings This is causing several checks in imported/w3c/web-platform-tests/dom/traversal/TreeWalker.html to fail. Firefox passes all the checks.
Attachments
Patch (11.27 KB, patch)
2015-09-23 09:54 PDT, Chris Dumez
no flags
Patch (11.37 KB, patch)
2015-09-23 11:38 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2015-09-23 09:54:42 PDT
Darin Adler
Comment 2 2015-09-23 10:35:54 PDT
Comment on attachment 261826 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=261826&action=review > Source/WebCore/dom/TreeWalker.cpp:134 > +template <TreeWalker::SiblingTraversalType type> > +Node* TreeWalker::traverseSiblings() I would write this: template<TreeWalker::SiblingTraversalType type> Node* TreeWalker::traverseSiblings() The desire to have it all on one line is probably just my personal quirk. I do like it better, though. The lack of space before the <> is more important to me and while I don’t know about everyone on the WebKit project I know that at least Anders strongly prefers it too. > Source/WebCore/dom/TreeWalker.cpp:145 > + m_current = sibling.release(); In modern code this should be WTF::move(sibling) rather than sibling.release(). > Source/WebCore/dom/TreeWalker.h:59 > + template <SiblingTraversalType> Node* traverseSiblings(); template<> with no space rather than template <>
Chris Dumez
Comment 3 2015-09-23 11:38:55 PDT
Darin Adler
Comment 4 2015-09-23 13:23:30 PDT
Comment on attachment 261833 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=261833&action=review > Source/WebCore/dom/TreeWalker.cpp:150 > + sibling = isNext ? sibling->firstChild() : sibling->lastChild(); > + if (acceptNodeResult == NodeFilter::FILTER_REJECT || !sibling) > + sibling = isNext ? node->nextSibling() : node->previousSibling(); I just noticed something redundant here. If acceptNodeResult is FILTER_REJECT, then there’s no reason to execute that first line of code setting sibling, because it gets overwritten by the second line of code. Maybe this is better? if (acceptNodeResult == NodeFilter::FILTER_REJECT) sibling = nullptr; else sibling = isNext ? sibling->firstChild() : sibling->lastChild(); if (!sibling) sibling = isNext ? node->nextSibling() : node->previousSibling(); Not really sure what’s best for efficiency and what’s best for clarity. We can definitely land it your way, but I just noticed this strangeness.
Chris Dumez
Comment 5 2015-09-23 13:50:29 PDT
Comment on attachment 261833 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=261833&action=review >> Source/WebCore/dom/TreeWalker.cpp:150 >> + sibling = isNext ? node->nextSibling() : node->previousSibling(); > > I just noticed something redundant here. If acceptNodeResult is FILTER_REJECT, then there’s no reason to execute that first line of code setting sibling, because it gets overwritten by the second line of code. Maybe this is better? > > if (acceptNodeResult == NodeFilter::FILTER_REJECT) > sibling = nullptr; > else > sibling = isNext ? sibling->firstChild() : sibling->lastChild(); > if (!sibling) > sibling = isNext ? node->nextSibling() : node->previousSibling(); > > Not really sure what’s best for efficiency and what’s best for clarity. We can definitely land it your way, but I just noticed this strangeness. You are right that the first sibling assignment is useless if acceptNodeResult == NodeFilter::FILTER_REJECT, however, it is should be cheap. The current code also has the benefit of being a bit more concise and matching the text of the DOM spec. I have a slight preference for keeping it this way.
WebKit Commit Bot
Comment 6 2015-09-23 14:41:10 PDT
Comment on attachment 261833 [details] Patch Clearing flags on attachment: 261833 Committed r190187: <http://trac.webkit.org/changeset/190187>
WebKit Commit Bot
Comment 7 2015-09-23 14:41:15 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 8 2015-09-28 11:38:56 PDT
Note You need to log in before you can comment on or make changes to this bug.