MobileFrontend / RL-target overrides the load queue. Any more not screened by Mobile is considered non-existent.

MathJax is adding it to the page, but MobileFrontend/RL-target is skipping it when it comes to execution.

Please ask the mobile team to review MathJax and whitelist it for target mobile.

Please ask the mobile team to review MathJax and whitelist it for target

mobile.

How do I contact the mobile team?

Is MathJax still being developed?
It should be possible to make MathJax work on mobile but it would require changes to the MathJax code base...

Looking at the source code here it currently doesn't make use of ResourceLoader (RL) but uses hooks which are not available on mobile.
http://people.cs.kuleuven.be/~dirk.nuyens/Extension_MathJax/MathJax.php.txt

My moving this to use RL it should be relatively easy to get it optimised and running on mobile...

I don't see how this bug is invalid.

Is MathJax still being developed?

Yes, very much so. (but see below)

It should be possible to make MathJax work on mobile but it would require changes to the MathJax code base...

Do you mean MathJax or the MediaWiki extension that integrates MathJax? I'm guessing the latter.

http://people.cs.kuleuven.be/~dirk.nuyens/Extension_MathJax/MathJax.php.txt

I think that's the wrong extension. The regular Math extension includes optional MathJax http://www.mediawiki.org/wiki/Extension:Math#MathJax

Not sure if that's related, but for the actual Android and iOS apps, you could also ship a copy of MathJax (slimming it down) to reduce network load and improve rendering speed.

Yeah, we use the Math extension's support for MathJax, not the separate MathJax-specific extension.

IIRC, Math uses a ResouceLoader-loaded stub to bootstrap MathJax, which then loads its own minified code.

It *should* work to mark the bootstrap stub as mobile-friendly... but we'll want to test to make sure it works as expected. We should also measure how heavy the download is; between libraries and fonts it may be a bit heavyweight for mobile.

Any progress on this? A user has just asked at http://en.wikipedia.org/wiki/Help_talk:Displaying_a_formula#No_MathJax_on_mobile.3F

If its not possible could it be made to switch to texvc mode when using a mobile?

(In reply to comment #7)

Any progress on this? A user has just asked at
http://en.wikipedia.org/wiki/Help_talk:
Displaying_a_formula#No_MathJax_on_mobile.3F

If its not possible could it be made to switch to texvc mode when using a
mobile?

I've done some work to make MathJax uses MediaWiki's resource loader, but I'll wait that MathJax 2.3 is released to finish it.

Here is a wmflabs instance that uses server-side TeX-to-MathML conversion and, for non-Gecko browsers, MathJax loaded via MediaWiki's ResourceLoader:
http://math-test2.instance-proxy.wmflabs.org/wiki/Fourier_series

one concern - will this JavaScript only be loaded by pages that use it? Also how much JavaScript would we be loading? We must remember that some users have very slow connections and we already send a fair chunk of code down the wire...

MathJax is only loaded by Wiki pages with <math> tags (and of course only when the MathJax mode is enabled). Also MathJax is split in several parts like TeX parser, HTML-CSS render etc and only the parts that are needed are loaded. However, it remains a big library and my experiments on an ipod with the page I just mentioned was that the rendering is very slow. The need of Web fonts make that even worse, especially when they are not cached by the system (bug 38751). The exact performance will have to be tried and studied carefully. A first step to test the water will be to make it an option for anonymous users (bug 48036).

(On the other hand, the native MathML of my Ipod's Safari in the page I mentioned I mentioned is fast)

Yes, it should only get loaded on pages that use it.

It may be a fair amount of JS (and associated WebFonts), so it could be a bit expensive on mobile networks... we'll want to try it out and test, probably.

MathJax is still an opt-in option, so I'd recommend we get it working on mobile and evaluate its heaviness -- there's some possibilities we can investigate with server-side SVG rendering if it really comes to it.

worse, especially when they are not cached by the system (bug

38751).
The exact performance will have to be tried and studied carefully. A first
step
to test the water will be to make it an option for anonymous users (bug
48036).

(On the other hand, the native MathML of my Ipod's Safari in the page I
mentioned I mentioned is fast)

Yes but is this on a WiFi connection or a 2G connection? We should optimise for the latter...

(In reply to comment #12)

Yes but is this on a WiFi connection or a 2G connection? We should optimise
for
the latter...

I "tested" on a WiFi connection. Doing more server-side conversions (either MathML or SVG) is probably the way we want to go.

IMHO, the obvious thing to do is for the mobile apps to *ship* a (slim) copy of MathJax to eliminate the connections issues at once. But in general, MathJax would be cached (like all resources) and could be pre-fetched on a faster connection.

physik wrote:

as discussed in 71787