MathJax initialization issues with MediaWiki / Wikipedia integration

[Brion Vibber]

Hi all --

I'm working on integrating MathJax into MediaWiki's 'Math' extension so we can start testing it out on Wikipedia.

I took some initial code that had been done as an on-wiki gadget and have been adapating it to MathJax 2.0 and to MediaWiki's native JavaScript loader system. This does an MJ configuration with a custom preprocessor, and tries to add some additional TeX macros.

It seems to be working well in Firefox, Safari, and Opera, but the math doesn't get transformed in Chrome or Internet Explorer (testing actively with IE 9 first, then will test earlier versions).

Any ideas?

Possibly I'm trying to be too clever by loading MathJax components through our ResourceLoader system (module loading and minification provided by MediaWiki)... would it be more reliable to load an entire stock configuration from the pre-minified files and then add to that configuration?

One thing I want to avoid is having a default configuration that replaces "$...$" TeX sections before we go ahead and replace our own items based on class...


Sample page:
http://leuksman.com/mw/index.php/Math_test


JS initializer:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Math/modules/ext.math.mathjax.enabler.js?view=markup

JS stub to list out files being loaded through ResourceLoader minifier/module-loader:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Math/modules/ext.math.mathjax.preload.js?view=markup

Custom preprocessor:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Math/modules/MathJax-custom/extensions/wiki2jax.js?view=markup

add'l macros:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Math/modules/MathJax-custom/extensions/TeX/texvc.js?view=markup

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

[Davide P. Cervone]

Thanks for asking.  I'll check into it and get back to you.  I suspect you are right that if you have replaced MathJax's loader by your own, there may be an issue there.  

In general, the combined configuration files are more efficient than loading the individual components separately.  We can certainly make a custom combined file for you.  Let me look at what you have done first and see what I can suggest.

Note that the default configuration doesn't use single-dollar delimiters.

Davide

[Davide P. Cervone]

OK, I've taken a look at the situation, and I think I know what it is (but it is difficult to diagnose with the minimized files and no ability to change anything for testing purposes).  Chrome is complaining about not being able to get the "config" property of a variable that is null, but it is not clear exactly which instance of something.config is the problem.  I suspect it is the one at line 28 of the ext.mathjax.enabler.js.  If I'm not mistaken, this is code from Nageh's extension, but I'm not sure exactly what he is trying to accomplish, here.  I think it is trying to overcome a problem he had with user-defined macros being overridden by macros in extensions, but this code will not do that properly.  He is linking to the signal that occurs when the extensions in the extensions array have been loaded, and sets TEX = MathJax.InputJax.TeX, but this signal can occur before the jax are loaded (see below).

In any case, this code will not do what Nageh intends, and so should be removed.  See if that helps.

I'm also a little concerned about your putting MathJax.js together with all the other files, as I think that may interfere with the timing as well.  Here's why:  at the bottom of MathJax.js is the initial MathJax queue that handles the startup process.  Part of that is loading the configuration file, loading the needed jax and extensions, and so on.  This queue is put in action at the time that part of the code runs, and so MathJax will start to take these actions right away.  Normally, that involves loading the configuration, extensions, jax and so on, which block the queue until those actions occur, and so the loading of the configuration, jax and extensions occurs before the rest of the queue runs.  But in your case, there is no configuration file, so nothing to load.  Similarly, the jax array is empty and no extensions have been specified at the time the queue runs, so there is nothing to do there, either, and MathJax goes through all those steps doing nothing, firing its signals that those actions have occurred.  Since the loading is occurring in the page onload handler (if I read things correctly), MathJax will also do its initial typeset pass (but will do nothing since no jax and no preprocessors are loaded yet).  That means MathJax will have finished its queue at the time that portion of the code is run, which is BEFORE the rest of large file (containing MathJax.js and all the other files) runs, so those things occur AFTER MathJax thinks it has already completed its entire setup process.  That means the timing will be off, and signals will be made that are misleading.

In your case, since you set up a tex/x-mathjax-config block that contains the one command mathJax.Config(), that configuration DOES occur at the proper time, and so the changes you make there and the signal hook are properly in place.  That means that the signal hook will run when the "End Extensions" signal occurs during the initial processing of the MathJax queue, which occurs before the code for the TeX input jax is available.  The would account for TEX being null and TEX.config causing an error.

You may ask why it works for the other browsers.  Well, there is a second reason the queue can be paused, and that is during the processing of stylesheets.  Some browsers require a delay in order to process style sheets before they are made available, and MathJax waits for that to occur, suspending the queue.  For those that do (e.g., Safari), the queue will be delayed between the configuration step and the loading of extensions and jax, and so the remainder of the big file will run before MathJax resumes the queue.  That would account for Safari and the other browsers that work.  If I remember correctly, IE doesn't need the delay, and it appears that Chrome doesn't either, which accounts for their failure.

If you eliminate lines 26 through 40, you may be able to get away with having everything all in one file like this, but I wouldn't guarantee it, and I'm a little concerned about it.

I would recommend that you only include MathJax.js in the ext.mathjax.enabler.js and allow MathJax to load its components in its usual way (it will be loading other pieces itself anyway).  The only difficulty is getting to set the root property before it needs to use that.  Here is a suggested approach (untested):

MathJax.Hub.Config({

  root: mediaWiki.config.get('wgExtensionAssetsPath') + '/Math/modules/MathJax',

  config: ["TeX-AMS-texvc.js"];

  "v1.0-compatible": false,

  styles: { ".mtext": { "font-family": "sans-serif ! important", "font-size": "80%" } },

  displayAlign: "left",

  menuSettings: { zoom: "click" },

  "HTML-CSS": { imageFont: null, availableFonts: ["TeX"] }

});

and then make a file names TeX-AMS-texvc.js in the config directory that includes

MathJax.Hub.Config({

  extensions: ["tex2jax.js","texvc.js","MathEvents.js","MathZoom.js","MathMenu.js","toMathML.js"];

  jax: ["input/TeX","output/HTML-CSS"];

  TeX: {extensions: ["noErrors.js","noUndefined.js","AMSmath.js","AMSsymbols.js"]}

});

MathJax.Hub.loadComplete("[MathJax]/config/TeX-AMS-texvc_HTML.js");

which we can make into a minified combined configuration file later.  This will require a second file to be loaded, but it should be more reliable.  We might want to talk more about what should be included in the combined version of this file.

There are some other issues that I will write about later, but I think this is the one that is causing the failure for Chrome and IE.

Let me know if that works.

Davide

On Mar 5, 2012, at 7:14 PM, Brion Vibber wrote:

[Davide P. Cervone]

PS, if you really think that you must have MathJax.js in a combined file with the others, there may be a way to make that happen.  I could try to work that out if it is necessary, but it seems to me that the two-file approach is preferable.

Davide

On Mar 5, 2012, at 7:14 PM, Brion Vibber wrote:

[Brion Vibber]

Davide -- thanks for the detailed response!

I've retooled our initialization as you recommended, loading just MathJax.js through our loader. The rest of the modules are now loaded one-by-one under MathJax's control, and I can confirm that it now works correctly in Chrome and on the Android Browser app. (I'll have to test IE tomorrow, all my VMs are on another machine.)

This also resolves a problem I had using our JS loader's debug (non-minimizing mode), probably caused by things ending up loaded in a less consistent order.

Switching to use the pre-minified configuration files later should decrease load time and still keep things under MathJax's control, so that seems like the way to go.


Diff view: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/113184

One downside is that this mixes our config file & custom code in with the main MathJax directory (I had kept them separate to make it easier to update our copy of MathJax). This isn't a huge burden though!

[Davide P. Cervone]

Brion:

Good to hear that you have gotten this to work more reliably in other platforms.  I feel confident that IE will work as well in this arrangement.  (I would test for you but I'm in the middle up updating my copy of Parallels so I can try out Windows 8 preview and IE10.)  

I didn't realize you were using an unpacked copy of MathJax.  You should be able to switch to the minified versions (the top-level copies from the original MathJax distribution) in order to help with the download sizes.  There is really no reason to use the unpacked copies unless you want to read the code yourself.  This will also mean you don't have to change the font directory, which you have to do now because the unpacked copy thinks it is one directory below the font directory.  (You should also change some settings for the menu close image, since it expects the image directory to be one above as well, but that is a detail for later.)

If you want to keep your changes more separate, there is a "local" subdirectory of the the config directory, and you could put TeX-AMS-texvc_HTML.js there and use

config: ["local/TeX-AMS-texvc_HTML.js"]

instead.  You could also make your own extensions/local directory and put your texvc and wiki2jax code there if you prefer.  But it is probably OK to work it the way you do now.  In the long run, you will combine them all into one configuration file that is loaded after MathJax.js rather than having each load separately as now, and that can go into config/local as well.

If you use git to maintain your copy of MathJax, then it really doesn't hurt to have other files there, as git will ignore them.

I will look at the current versions of the files tomorrow and see if I can suggest anything else, but it looks better now.

Davide