Inconsistent behaviour across browsers (Chrome / Firefox)

[ilariaschinina]

I am using fontoxpath in a project and noticed some inconsistent behaviors between Chrome and Firefox.
On Chrome the queries //div and //*[name()='div'] find and match all the divs in the document.
On Firefox, fontoxpath with the very simple query //div, returns an empty array, while with the more convoluted query //*[name()='div'] matches the divs.

I built a small project where the issue can be reproduced, you can find more details about the issue in the README and test yourself:
https://github.com/ilariaschinina/fontoxpath-test-project

Let me know if I can provide further details or clarifications.

Best,
Ilaria

[DrRataplan]

Hello Ilaria,

This is because of namespaces. If no namespace resolver is passed, I make a default one. This is defined at https://github.com/FontoXML/fontoxpath/blob/master/src/evaluationUtils/buildEvaluationContext.ts#L41. In Chrome, this does the following:

document.lookupNamespaceURI('')
'http://www.w3.org/1999/xhtml'

In FireFox, I get this:

document.lookupNamespaceURI('')
null

However, all elements are in that namespace. Since I do not really have a stable way to determine that for these queries a user means to point the default prefix to the HTML URI, I'm a bit stuck. If you have any better ideas I'm happy to listen!

The easiest way to always make this work is by passing a namespace resolver. Something like this should fix it:

evaluateXPathToNodes(
  '//div',
  window.document,
  null,
  (prefix) => {
    switch (prefix) {
      case '': return 'http://www.w3.org/1999/xhtml';
      default: return undefined;
    }
  });

Of course, wrapping FontoXPath in a new function makes it easier to use:

const evaluateXPathToNodesOnHtml = (query, contextItem) => evaluateXPathToNodes(
  query,
  contextItem,
  null,
  (prefix) => {
    switch (prefix) {
      case '': return 'http://www.w3.org/1999/xhtml';
      default: return undefined;
    }
  });

Kind regards,

Martin

[bwrrp]

It looks like Firefox' behavior is wrong in this case compared to the DOM spec. There's a 9 years old bug open for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1061578

[ilariaschinina]

Hello Martin,
thanks for the detailed answer and for suggesting a solution.
Passing a namespace resolver does the job 👍

Best,
Ilaria