MathJax 3 completion handler fails if the content contains processing instructions

[bthomale]

Issue Summary

We found a bug where, when using tex-mml-chtml conversion, if the input file is xhtml containing a processing instruction, the completion handler never fires. Additionally, the javascript will show the following error in the console:

Unhandled Promise Rejection: TypeError: t.getAttribute is not a function. (In 't.getAttribute(e)', 't.getAttribute' is undefined)

We've replicated this in WebKit / Safari on macOS, iOS. And also in the embedded webkit view in Android.

Essentially, it's iterating through the content looking at the "class" attribute of various nodes. Somehow it is assuming they're all elements, and when it hits a processing instruction node (where getAttribute is not defined) it throws this error. You can see exactly what is happening if you turn on "break on exceptions" in the WebKit debugger.

We noticed that it only happens during TEX input processing, which we don't need. Turning off TEX works around the problem, which is what we have done. But it's still a bug, so I thought you might be interested in looking at it.

I've included 3 different versions of the file to illustrate this:

1. tex-mml-chtml-with-pi.xhtml

This is the one that fails. It has a completion handler defined that logs "done" to the console. If you open up the console you'll see the error I described, and "done" is never logged.

2. tex-mml-chtml-no-pi.xhtml

This illustrates that without the pi the example completes successfully and logs "done" to the console.

3. mml-chtml-with-pi.xhtml

This illustrates that with the pi, but with mml-chtml ONLY (no TEX) it also completes successfully and logs "done" to the console.

Steps to Reproduce:

1. Open the attached file tex-mml-chtml-with-pi.xhtml
2. Open the debug console
3. Refresh the page. You'll see the error and that "done" is never logged.

Technical details:

• MathJax Version: 3.1.2
• Client OS: macOS 11.2.3
• Browser: Safari 14.0.3

^ I was able to replicate with that. Easier than trying to reproduce with mobile.

Supporting information:

tex-pi-bug.zip

See the above attached zip for the promised example files. Just open them in Safari.

[dpvc]

Thanks for the report. I can reproduce the issue. Frankly, I have never seen these processing instructions before, so was unaware even of their existence! I will have to modify the code to skip over non-Element nodes.

[pkra]

FWIW, XML processing instructions are not valid in (x)html5.

[dpvc]

Thanks @pkra. I'm not able to find a reference to that. I see where they are not allowed in HTML5, but I can't find a restriction in XHTML5. Do you have a citation for that?

[pkra]

(I don't mean for this to have any bearing on what the MathJax team decides to support.)

IIUC it's difficult to find because there's not really such a thing as XHTML5. E.g., https://en.wikipedia.org/wiki/HTML5#XHTML_5_(XML-serialized_HTML_5) writes

XHTML 5 is simply XML-serialized HTML 5 data (that is, HTML 5 constrained to XHTML's strict requirements, e.g., not having any unclosed tags), sent with one of XML media types.

So HTML5 does not allow processing instructions and XML serialization only adds restrictions, it does not remove any.
In any case the nu validator will complain about these documents (though initially about the missing doctype, then about the intial instruction).

That being said, given that this is coming from VitalSource (who, ahem, should really become a MathJax sponsor?), it probably comes from an epub file and, alas, epubcheck does allow processing instructions. [Still, this should really be sorted out in production]

[dpvc]

@pkra, thanks for the additional information. I was mostly just curious about what the various standards allow. I have worked out a means of ignoring those nodes that should resolve the issue, but your comment piqued my interest.

[bthomale]

As far as I know, processing instructions are valid in xhtml (and valid in epub files). And yes, this came from debugging an issue with a real epub on our platform, so people are using these.

Thanks for fixing this for us!

[dpvc]

I have made a pull request to resolve the issue. In the meantime, you can use the following configuration to work around the problem for now.

MathJax = {
  startup: {
    ready: function() {
      //
      //  Patch the HTMLAdaptor's kind() method to return '' for node types we can't process.
      //
      const {HTMLAdaptor} = MathJax._.adaptors.HTMLAdaptor;
      HTMLAdaptor.prototype.kind = function (node) {
        const n = node.nodeType;
        return (n === 1 || n === 3 || n === 8 ? node.nodeName.toLowerCase() : '');      
      };
      
      //
      //  Subclass the DOM string walker to handle unknown node types
      //
      const {HTMLDomStrings} = MathJax._.handlers.html.HTMLDomStrings;
      class myDomStrings extends HTMLDomStrings {
        handleContainer(node, ignore) {
          if (this.adaptor.kind(node) === '') {
            this.pushString();
            return [this.adaptor.next(node), ignore];
          } else {
            return super.handleContainer(node, ignore);
          }
        }
      }
      
      //
      //  Use our DOM string class instead of the usual one
      //
      MathJax.config.options = {DomStrings: new myDomStrings()};
      
      //
      //  Do the usual processing
      //
      MathJax.startup.defaultReady();
      
      //
      //  Inform us when it's done
      //
      MathJax.startup.promise.then(function() {
       	console.log("done");
      });
    }
  }
};

[dpvc]

PS, this could be put into a separate script file that is loaded before MathJax itself if you need it for multiple pages.