[Math Processing Error]s with MathJax 2.5 => can't typeset detached

[cben]

MJ 2.5 is out and the demo page now points to it (it uses latest/). It consistently gives [Math Processing Error] on about half the math — same formulas every time:

• AMScd: $ \begin{CD} A @<<< B @>>> C\\ @. @| @AAA\\ @. D @= E \end{CD}$
• \begin{aligned} \nabla \times \vec{\mathbf{B}} -\, \frac1c\, \frac{\partial\vec{\mathbf{E}}}{\partial t} & = \frac{4\pi}{c}\vec{\mathbf{j}} \\ \nabla \cdot \vec{\mathbf{E}} & = 4 \pi \rho \\ \nabla \times \vec{\mathbf{E}}\, +\, \frac1c\, \frac{\partial\vec{\mathbf{B}}}{\partial t} & = \vec{\mathbf{0}} \\ \nabla \cdot \vec{\mathbf{B}} & = 0 \end{aligned}
• \begin{equation}x+1\over\sqrt{1-x^2}\label{ref2}\end{equation}
• \begin{align} x& = y_1-y_2+y_3-y_5+y_8-\dots && \text{by \eqref{ref1}}\\ & = y'\circ y^* && \text{(by \eqref{ref3})}\\ & = y(0) y' && \text {by Axiom 1.} \end{align}

=> Yep, it happens with environments - I changed a $$..$$ to \begin{equation}..\end{equation} and it broke.

No errors in log; the only suspicious thing is repeating " Fallaback flushMarkTextQueue: 2" (used to be 1).

[cben]

confirmed that MJ 2.4-latest works.

[cben]

menu -> Show math as -> Error message => Error: Cannot read property 'firstChild' of null

[cben]

The obvious processEnvironments: true didn't help. (docs are quite clear it defaults to true anyway)

[cben]

Same error also accissible in console as MathJax.Hub.lastError.message.

In firefox it gives different error: q is null

[mull]

I'm having the same trouble in a different project. Did you ever solve this?

[cben]

Not yet, I stayed on 2.4 so far. I'll try to attack it today. 16.03.2015 14:14 пользователь "Emil Ahlbäck" [email protected] написал:

I'm having the same trouble in a different project. Did you ever solve this?

— Reply to this email directly or view it on GitHub https://github.com/cben/CodeMirror-MathJax/issues/33#issuecomment-81612540 .

[mull]

We reverted back to 2.4 as well for now. The problem for us lies in using iframes to host the previews, but loading mathjax in the outer document. Due to some legacy issues we can't just switch to divs, though that would solve it. Good luck!

[cben]

Reported with minimal case at https://github.com/mathjax/MathJax/issues/1185

All errors I saw were from CHTML code new in 2.5. They go away if I disable Fast Preview (and don't choose Fast HTML as the renderer). Fast Preview can be set off by default, see http://www.mathjax.org/mathjax-v2-5-now-available/

[cben]

@mull Forgot to update here: MathJax folks replied to that bug explaining my use case was never supported. I'm calling Typeset() on detached DOM nodes, which happened to work (but not guaranteed to be correct) with 2.4's outputs which may temporarily move such math into DOM and back, but doesn't with 2.5's CHTML renderer. The conclusion is that I must attach my math somewhere inside the DOM before calling Typeset (and preferably avoid display: none, see https://github.com/mathjax/MathJax/issues/1179#issuecomment-97897405).

[Issue very specific to my project: once it's typeset I can give the element to CodeMirror but then I won't be able to optimize with MathJax's Rerender() and friends (which I don't yet, #15) because they're async and CodeMirror may attach/detach the element I gave from the DOM at any moment as lines are scrolled in/out of screen.]

[cben]

I now tried the simplest possible fix, which is to markText immediately instead of after typesetting. I hoped this will both ensure typesetting within the DOM and fix #41. But the former doesn't work - if it's far enough outside the viewport, CodeMirror doesn't attach it to the DOM so it still breaks with 2.5. (It would also complicate or prevent the optimization of calling Typeset() on lots of math at once.) So I must have a separate typesetting area. (and for #41 I'll need a temporary non-widget markText)

[theyak]

For kicks I wrote a jsFiddle with this issue. We will have to stay with 2.4 for now.

With 2.4: http://jsfiddle.net/35L1pegp/ With 2.5: http://jsfiddle.net/35L1pegp/2/

Things rendered properly with 2.5 if Fast Preview was turned off, but it was still 4 times slower than 2.4 out of attached DOM rendering. CommonHTML rendering method in 2.6 was just as slow as HTML-CSS.

[cben]

I implemented in-DOM rendering but now that I can run 2.5 and 2.6 I'm also seeing dramatic slowdown:

7.5sec with 2.4.0, 50sec with 2.5.3, 50sec with 2.6.0-beta.1.
That's with Chrome on linux, HTML-CSS and fast preview on (which is useless - math stays hidden until fully rendered).
{"fast-preview": {disabled: true}} makes no measurable difference. Surprisingly, CommonHTML gives no improvement either - also 51sec. SVG also 48sec.

BTW, out-of-DOM with 2.4 was slower: 15sec vs 7.5sec for in-DOM. So 2.4 with in-DOM is so far fastest.

Firefox with 2.6: HTML-CSS (no preview) took 104sec, Common HTML 98sec, Fast HTML 70sec, SVG 71sec, even MathML took 54sec! That's compared to 2.4: HTML-CSS 24sec, SVG 10sec, MathML 10sec.

It's so damn slow I'm seeing 1-2 formulas at a time getting replaced...

• I'm queueing Typeset for each formula separately. That's known as bad for performance (it prevents mathjax from scheduling a lot of measurements into one reflow). Perhaps this 2.4->2.5 speed regression is limited to such usage?
  But your jsFiddle only calls Typeset once on 1 formula. And wasn't CommonHTML suppossed to do few to none measurements?

I'll try to dig deeper (and produce simpler tests, with permalinks per version/config; ideally jsperf?) and report on MathJax mailing list. I'm perplexed how it's possible that a big regression went unnoticed; normally people experienced 2.5 and 2.6 as faster...

Oh, and I should try KaTeX.

[cben]

I implemented batched typesetting in 7e1851ead6b3b7bd6c042946d79233b28853d2e5: collect many formulas under one div and call MathJax.Hub.Queue(["Typeset", ...]) once on this div. Now MathJax 2.5 and 2.6 are as fast as 2.4 (and 2.6's Common HTML is faster than 2.4)!

This may explain how come there was a big 2.4->2.5 slowdown that went unnotticed: it only happens when you dynamically queue many Typeset calls, which is a rare use case (most people have MathJax process existing content once when it loads). I'll try to create minimal cases and report to MathJax devs, but it'll take me time.

The original issue here is fixed, leaving it open until I:

• [ ] make 2.6 fast in all cases (large edits still queue many small Typesets, need smarter batching heuristic)
• [ ] report slowdown upstream.