various issues on puzzling.SE

[pkra]

From puzzling.SE.

On this question, I see the following

• the FastPreview crashes half-way through the page (TeX is still in place). The console reports MathJax.js?config=TeX-AMS_HTML-full:19 Uncaught TypeError: Cannot read property 'insertBefore' of null
• If I deactivate the Fast Preview, then I see the problem described in the post -- furthe down in the page, the rendering is all over the place and equations are duplicated. This seems to roughly match the point where the FastPreview crashes (the last answer from BigBlackBox)

I'll see if later versions of Chrome suffer from this.

[pkra]

CommonHTML and SVG don't seem to be affected.

[pkra]

Also, I used the standard modern.ie VM for Win7, IE9 for this.

[pkra]

Same on Chrome 49.0.2623.47 beta-m, Win7.

[dpvc]

I can reproduce on Chrome 48.0.2564.97 on Mac OS. It is not dependent on the Fast Preview or Assistive MathML settings for me, and I see no errors in the error log.

[dpvc]

The state of the DOM is very similar to that in issue #1171. I'm wondering if there isn't a second MathJax.Hub.Typeset being made somewhere that doesn't use the MathJax queue. There are several occurrences of raw MathJax.Hub.Typeset calls in the javascript loaded for the page, but since the code is minified, it is hard to tell when they get used. Rerendering the page (not reloading but calling MathJax.Hub.Rerender() in the console) clears the problem, so it is not directly an output error. It really looks like two Typeset calls being interleaved.

[pkra]

Thanks. I'll follow up with SE.

[m0sa]

Users are reporting getting the same error here, I couldn't repro it with the provided steps though.

[dpvc]

I believe this particular report will be resolved by pull request #1396. It is due to the page being replaced before MathJax is finished typesetting it, something I thought the code being used prevented. If the editing and MathJax's typesetting are no longer synchronized properly, that could account for the other problem as well.

[dpvc]

The issue1384 branch of my form of MathJax include additional checks to test for this.

[dpvc]

I have finally been able to make some headway on the issue in puzzling.SE. It turns out to be a combination of issues. First, SE doesn't use MathJax.Hub.Queue() to perform its MathJax.Hub.Typeset() commands, so that does allow processing to become interleaved, but that turns out not to be the main issue. Another important factor is that they modify the page while MathJax is typesetting it, which removes some of the math that MathJax is trying to work on. MathJax should be able to handle that, but there are a couple of places (in addition to the ones already included in the commits listed above) where this causes MathJax to operate incorrectly. In particular, if some math in the list of expressions MathJax is typesetting is removed from the page, the HTML-CSS output jax will fail to mark the rest of the math as being processed. That means the next time MathJax is asked to typeset the page, all the math is typeset again; but because the output is already there, a second copy gets added, which gives the bad output listed in the puzzling.SE post.

It took quite some investigation to figure out the interactions in the complex environment of SE, but I do have some changes that should fix this problem.

[dpvc]

I have added the new fixes to the issue1384 branch.

[dpvc]

==> Merged.

[dpvc]

==> In testsuite

Parsing/issue1384-1.html
Parsing/issue1384-2.html
Parsing/issue1384-3.html