Stop wrapping math in <script type="math/tex">...</script>.

[drgrice1]

This used to be handled directly by MathJax long ago, but it no longer does so. Using \(...\) or \[...\] now works. So just do that. Also make sure that &, <, and > are properly HTML escaped. This actually gets done when the post_process_content method is called, but just in case the general_math_ev3 method also does this. Note the Mojo::DOM parser is smart enough not to doubly escape these things.

The script tag handling in the webwork2 mathjax-config.js file seems to be causing issues in some cases, and switching to using \(...\) or \[...\] fixes those issues. See #1498 for details.

It is also time to start doing some code clean up. I just did some minimal clean up of the general_math_ev3 method.

[somiaj]

I can confirm it fixes the issue. Probably needs a hotfix.

[dpvc]

If there are no more <script type="math"> tags being generated, you should be able to remove the lines

https://github.com/openwebwork/webwork2/blob/c7060fe858cb27b17aad5cf77574ff7d1ae3e1fa/htdocs/js/MathJaxConfig/mathjax-config.js#L147-L171

from the MathJax configuration, as well as

https://github.com/openwebwork/webwork2/blob/c7060fe858cb27b17aad5cf77574ff7d1ae3e1fa/htdocs/js/MathJaxConfig/mathjax-config.js#L133

It must have something to do with the faked MathItem that is created there. I'll look into it, but since these seems to resolve the problem, I'm n to sure ho much time I can put to it.

[drgrice1]

I do plan to put in a pull request to webwork2 to remove that script tag handling in mathjax-config.js. I have it already committed in a branch. I was just tweaking this one with the HTML escaping. I need to check on the escaping of the feedback case in PG.pl yet.

@somiaj: The > doesn't really need it as long as there is not matching unescaped < preceding it.

[somiaj]

Should we worry about breaking third party macros and the likes if we remove lines that deal with the script tags? I am not worried if we break them, just something to consider.

[drgrice1]

How would removing the script tag break a third party macro?

[somiaj]

@drgrice1 Yea, I knew they didn't need to be escaped, I was just thinking in terms of consistency, someone might wonder why < changes to < but > doesn't. Though might not affect the rendering in the end anyways.

[somiaj]

I was just considering what was happening of some third party macro was using <script type="math/tex">...</script> for their math output in HTML_MathJax mode. But probably not being done or something to worry about.

[drgrice1]

Okay, since the feedback case is handled in post processing anyway, and always goes through Mojo::DOM, that case is always escaped. So this is good as is.

[drgrice1]

@somiaj: You might note that in the usual way that problems are rendered via the translator, the > ends up getting escaped anyway when the post_process_content method of the translator is called, and the problem text is parsed by Mojo::DOM.

[drgrice1]

I switched to using HTML::Entities::decode_entities and encode > as well. Since the HTML::Entities package is available, might as well. It is already used more generally for HTML display mode below.

[somiaj]

Double checked again that the issue is fixed. I still think this needs to be a hotfix as the broken problem was originally from the OPL.