Incorrect result when running the same xpath against a similar document

See below example test.

const nameSpaceDocument = new slimdom.Document();
const namespaceElement = nameSpaceDocument.createElementNS("http://test.com", "name");
namespaceElement.textContent = 'name1'
nameSpaceDocument.appendChild(namespaceElement);

chai.assert.equal(evaluateXPathToString('/name/text()',	nameSpaceDocument), 'name1')

const slimdomDocument = new slimdom.Document();
const nameElement = slimdomDocument.createElement("name");
nameElement.textContent = 'name2'
slimdomDocument.appendChild(nameElement);

chai.assert.equal(evaluateXPathToString('/name/text()',	slimdomDocument), 'name2')

The first document includes a namespace on the name element. The second document does not. The second assertion will fail, however if you change the order of the assertions it works as expected. If you change the second xpath to just be ‘/name’ it also works as expected. Looks to be a caching issue?

[DrRataplan]

Found it, when compiling an expression, we try to return a fully cached expression if both the expression string the static contexts match another run. This fails here. We then try to get a ‘half compiled’ result, which can occur when someone just asked for a bucket of a selector, but did not execute it. Getting the bucket of a selector does not require static compilation, but does require a ‘normal’ compilation. However, this mistakingly gets any compilation result. See https://github.com/FontoXML/fontoxpath/blob/master/src/parsing/compiledExpressionCache.ts#L129, which in the end does https://github.com/FontoXML/fontoxpath/blob/master/src/parsing/compiledExpressionCache.ts#L46.

The fix would be to only use the ‘halfcompiled’ cache here.

[ymor]

Hi, Yes it is now working as expected. Thanks for the quick turnaround!