494842 - document.evaluate discrepancy with absolute xpath expressions

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Juriy "kangax" Zaytsev]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

Given this simple script:

var el = document.createElement("div");
el.innerHTML = "<p>a</p><p>b</p>";
var result = document.evaluate("//*", el, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);

alert(result.snapshotItem(0));

Firefox 3.0.10 thinks it's "[object HTMLParagraphElement]", WebKit - "[object HTMLHtmlElement]" and Opera 10a returns null.

It's not clear whether absolute path should be treated as relative when matched in a context of another element, but it looks like that's exactly what Firefox is doing here.

WebKit folks think that Firefox might be getting this wrong <https://bugs.webkit.org/show_bug.cgi?id=25931>

Could anyone please clarify which behavior is correct?

Reproducible: Always

Comment 1

[Phred]

I beleive Webkit and Opera are more correct in this case.

Webkit is correct in that the predicate '//*' is not respective of scope. '//' means anywhere in the document.

However I'm not sure of the logic Opera is using exactly, but executing xpath in the context of a node that is not a part of the current document seems strange and like it should throw an error or return null.

Comment 2

[Phred]

Attachment: testcase showing differences before and after appending node to the document

I believe my diagnosis of Opera's logic is correct. Once you add the node into the document, Opera returns the same answer as Webkit.

Someone suggested that firefox may be treating the node as its own root since it is not a member of the document. I'm not sure who is correct in this case. I'm sure that Webkit's implementation is not. Before and after being appended, the anser is always [object HTMLHtmlElement].

Browser: Before -> After append
FF3-3.5: [object HTMLParagraphElement] -> [object HTMLHtmlElement]
FF2: null -> [object HTMLHtmlElement]
Opera: null -> [object HTMLHtmlElement]
Saf4: [object HTMLHtmlElement] -> [object HTMLHtmlElement]

So firefox used to be identical to Opera and then something changed.

Comment 3

[Phred]

According to the spec http://www.w3.org/TR/xpath#path-abbrev :

"//para selects all the para descendants of the document root and thus selects all para elements in the same document as the context node"

There exist no parent document for the context node, thus null seems like a vaiable answer. This is a regression from FF2.

Comment 4

[Alexey Proskuryakov]

In this test, the context is not in document tree, but it is owned by the document anyway. So, I think that WebKit behavior (empty result) is the most compliant here.

See also document.evaluate in XPath DOM spec:

"The context is context node for the evaluation of this XPath expression. If the XPathEvaluator was obtained by casting the Document then this must be owned by the same document and must be a Document, Element, Attribute, Text, CDATASection, Comment, ProcessingInstruction, or XPathNamespace node."

There is no requirement for the context to be in document tree, as far as I can tell.

Comment 5

[Alexey Proskuryakov]

> So, I think that WebKit behavior (empty result) is the most
> compliant here.

That is, empty result in original case, or [object HTMLHtmlElement] in the attached one.

Comment 6

[Phred]

Firefox 2x and Opera are the only ones that return an empty result (null). Is that what you are referring to? 

Webkit ignores the fact that the context node is not in the document and goes to the root.

Comment 7

[Alexey Proskuryakov]

> Webkit ignores the fact that the context node is not in the document and goes to the root.

Yes, I'm saying that this is correct behavior according to XPath 1.0 and DOM 3 XPath specs. Logically, there is also no reason to require that the node is attached - it's only the ownership relationship that matters (ownership as in Document.adoptNode(), for example).

Comment 8

[Phred]

It seems illogical to find some element in the tree in the context of a node that is not a member of that same tree.

Comment 9

[Alexey Proskuryakov]

This is indeed a matter of opinion to some degree, because the XPath 1.0 spec only talks about XML documents, and detached subtrees are out of scope for it. However, the quote from XPath DOM spec that I gave in comment 4 implies that it's the ownership and not containment that is important for XPathEvaluator.

Besides, evaluate() is documented to either return an XPathResult object or to raise an exception, so null is not a valid option.

Comment 10

[Phred]

I never suggested that evaluate() should return null. I am saying that evaluate().snapshotItem(0) should return null when xpath is executed in an invalid context (as is the case in ff2 and opera).

Comment 11

[Diego Perini]

Juriy,
in this case I believe the only XPath difference between the mentioned browsers is in the precedence they give to the "//" over the passed parameter context.

I don't know very much about XPath but removing those two slashes from the query seems fixing the difference; all of FF 3.0.10, Safari 4 and Opera 9.64 will then return "[object HTMLParagraphElement]".

To test this a bit more I also made the following change to your test:

var result = document.evaluate("*", el.ownerDocument, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);

and now all of them return "[object HTMLHtmlElement]" as expected.

I don't now who is buggy here, in my view the passed parameter context should have precedence and overwrite the one specified in the query (if present).

Comment 12

[Juriy "kangax" Zaytsev]

@Diego

I noticed it too and mentioned in a comment to WebKit ticket: <https://bugs.webkit.org/show_bug.cgi?id=25931#c2>

Comment 13

[Tyler Downer [He/Him]]

This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.

Comment 14

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.