Sniffing for "Firefox" in MathJax is very broken, breaks Wikipedia and other sites in upcoming Firefox

[bzbarsky]

Looking at MathJax.js, it has:

isFirefox:   (window.netscape != null && document.ATTRIBUTE_NODE != null && !window.opera),

This will test false because window.netscape is not defined. Hopefully this is not used for anything.

And then later on this file has:

  browser.isMobile = (navigator.appVersion.match(/Android/i) != null ||
                                 navigator.userAgent.match(/ Fennec\//) != null);

which is wrong for various upcoming things like Firefox OS. Again, hopefully this is just not used for anything...

[bzbarsky]

More details:

1) window.netscape is not defined starting with Firefox 17, unless a security fix gets reverted. 2) The isFirefox thing does seem to be used. And when the browser is not sniffed as something MathJax knows about it looks like MathJax falls back on "don't work" instead of falling back on "follow standards". This breaks, for example, math display on Wikipedia in Firefox 17 and up.

[bzbarsky]

One more note: I know I've raised the issue about falling back to standards before... Please fix that! Right now you're locking new browsers out of sites using MathJax, and said sites will keep breaking even in existing browsers as those browsers remove the nonstandard hackery the sniffing is based on...

[fred-wang]

Additional information: this bug can be seen in the HTML-CSS output mode, when one does not have local fonts installed. In that case instead of using the MathJax Web fonts, MathJax does not recognize Firefox 17 and fallbacks to the image fonts (like in mathjax.org) or fails with Math Processing Error (like in Wikipedia).

Davide: MathJax's philosophy is that "it just works" but this incorrect browser sniffing is a serious issue. Do we really want to continue to support old browsers at the price of breaking the latest versions? Personally, I think we should stop with these image fonts and always fallback to Web fonts, assuming that all modern browsers support this feature and so discontinuing support for the oldest browsers. Even using SVG or MathML modes when loading the Web fonts fails would be better, in my opinion. Can you remind me why we still want this image fallback?

[fred-wang]

http://weblogs.mozillazine.org/bz/archives/2011/03/capability_sniffing_done_wrong.html

Defaulting to the standard Web fonts fallback would certainly solve this spectacular failure. However, there is a more general problem. MathJax tries to workaround many layout bugs in browsers like in the HTML-CSS output:

https://github.com/mathjax/MathJax/blob/master/unpacked/jax/output/HTML-CSS/jax.js#L2644

and so wants to know on which browser it is running and not only whether the browser supports a given feature...

[bzbarsky]

I think separating things like "what capabilties do I have" (which should be tested for via direct capability testing or by assuming the browser supports standards) and "what bugs do I need to work around" (which should be tested for directly if possible, and if not ideally should not assume that browsers will never fix the bug) is a good idea....

And yes, thank you for digging up that blog post!

[dpvc]

@fred-wang, the main use of image fonts today is not to support older browsers (though it does that), it is to handle these cases:

1. When MathJax is used with local files (file:// URL's) in Firefox when MathJax is not in the same directory as the HTML page that loads it (and the same-origin policy prevents those fonts from being loaded). In this case, web-fonts are not used, and MathJax uses image fonts if there are no local fonts available.
2. When web-based fonts don't arrive in a timely fashion. This can happen in Firefox when the MathJax distribution is in a different domain and the access control headers haven't been set to allow cross-domain loading of the fonts. It also happens on mobile devices with slower connections when the web fonts take too long to download.

I agree that it is reasonable to make use of web fonts as the default for unknown browsers at this point (which was not the case when the HTML-CSS output jax was first written), and will make changes to accommodate that.

The isFirefox value is used in only two places in the HTML-CSS output (and in only one other jax, the NativeMML output jax). The first is in deciding if web fonts are to be used, and the second is in determining whether a special message should be issued when web fonts fail to load (indicating the cross-domain issue as a likely problem). Changing the default to assume web-fonts should eliminate the problems with the first of these, and the second is not crucial functionality.

I am really not interested in having a debate about feature detection, and although I agree with doing that in principle (and already do it in some cases), many of the issues that MathJax needs to work around are not detectable.

[dpvc]

The issue317 branch of my fork of MathJax contains the change to make web fonts the default.

[fred-wang]

OK, I see that you have added window.mozPaintCount != null to test Gecko when window.netscape no longer exists. However, it seems you have commented out the isFirefox and isSafari functions and I'm not sure that's what you want.

In the future, I'm wondering if we will eventually get rid of these image fonts. Everybody complain about their sizes and I only remember one MathJax supporter that was happy with them (and that was before we get the SVG output Jax I think). Now that we have the SVG output Jax, this fallback does not seem essential and moreover is of poor quality. BTW, I'm also wondering if we should consider using only Web fonts in the WOFF format in the future, as browser vendors are converging towards this format. That will reduce the size of the fonts/ directory a lot.

Regarding the use of isFirefox, we also expose this as a public function (as well as the Browser.Select switch). So even if we would be able to detect every issues, we will still need to keep it for the users.

[bzbarsky]

dpvc, what issues is MathJax having to work around in Gecko? Are there bugs filed on them, do you know?

If I can get you to the point where you don't have to keep sniffing for non-standard stuff to detect Gecko, that would be awesome from my point of view. ;)

[fred-wang]

I use MathJax's Firefox detection on my blog to ask MathJax to parse only the TeX comments of my blog (as I use directly MathML in the blog entries which Firefox can display) and choose the MathML output (instead of the default HTML+CSS). I guess other users do a similar use of MathJax's browser detection. So here it's really a matter of choosing something according to user's preference, not to workaround an issue on a specific browser.

I agree however that in general we should try to do feature detection when we really want to workaround a missing feature and report the bugs upstream so that they can be fixed. The latter is what I plan to do (*), but I haven't analysed yet all the issues that MathJax try to workaround. One problem is that issues appear in new versions while other are fixed (but still present in old browsers) so it's complicated to keep everything up-to-date.

(*) On Mozilla's Bugzilla, the tracking bugs is bug 745687 ; on Webkit's Bugzilla the tracking bug is 84012.

[dpvc]

@fred-wang, right, I had commented out the isFirefox and isSafari properties while I was testing the fallback and forgot to take them out. I have updated the branch this morning.

I understand your concern about the image fonts. I think the time to make the change is when we make new changes to the MathJax fonts (lie adding the glyphs we need for stretchy characters). At that point, the image fonts would also need to be updated, and rather than doing that, we can probably drop them. But switching over to another renderer is harder (as opposed to modifying the one in use), and will need some more extensive coding and testing, so will have to wait for a future version. There is also the question of what to do for IE8 and below if web fonts can't be loaded, since it can't use the SVG output mode; there are still a lot of users who have stayed with Windows XP after the fiasco of Windows Vista and so are limited to IE8 as the highest version they can run.

@bzbarsky, I will look to see what the issues are (very few for Gecko). The NativeMML issues Fred already knows about and has filed bugs for, and many have been resolved. For HTML-CSS, the things that I remember are the same-origin issue for local files when MathJax is in a different directory (not a bug, but something that MathJax must contend with), and a problem with using combining characters for accents (since the accents are placed by hand, they don't appear next to a character that they can be combined with, and so they disappear; this is not technically a bug either, but again something MathJax has to content with -- not just in Firefox but in other browsers as well).

[bzbarsky]

Seems like the same-origin thing could just be done for all UAs, as could the other if it's not Gecko-specific....

Please do let me know about any Gecko-specific bugs that Fred is not already dealing with!

[pkra]

Just some data regarding IE: 12.5% of CDN use is by IE8 -- half of all IE users right now. (We serve 2TB per month.)

[fred-wang]

Note: netscape.security has temporarily been added back in Firefox Nightly since 2012-09-27.

I verified with a 2012-09-21 Firefox nightly that

http://devel.mathjax.org/testing/testsuite/API/Hub/Select-1.html?mathJaxPath=http://devel.mathjax.org/testing/mathjax/dpvc/develop/ http://devel.mathjax.org/testing/mathjax/dpvc/develop/test/

fail,

http://devel.mathjax.org/testing/testsuite/API/Hub/Select-1.html?mathJaxPath=http://devel.mathjax.org/testing/mathjax/dpvc/issue317/ http://devel.mathjax.org/testing/mathjax/dpvc/issue317/test/

pass. I also commented out the isFirefox section (as you probably did) and verified that the image fonts are used on the develop branch while the Web fonts are used on the issue317 branch. All the tests above work correctly with a Firefox release.

Setting this "Ready For Release" so that we can take it for the MathJax 2.1. Other issues like the one with isMobile, browser bugs to report and possible workarounds to removed can be handled separately after MathJax 2.1 (I wanted to do it anyway).

The isFirefox failure could have been detected by

API/Hub/Select-1.html

so I set this "In testsuite".

[dpvc]

Thanks, Fred. I will merge, and we can handle the other parts in the future, as you suggest.

[dpl]

not sure if this is the right location to post, but for some reason, web fonts do not work for me with Firefox 15.0.1 (diagnosed via test/index.html). My zero-th order assumption would be that this is due to the same problem as spotted here. I'll be happy to look into it further, but my question is: how to debug what is really the cause. Thank you (also for redirecting me where else to post) -dpl

[dpvc]

@dpl you can tell if MathJax has properly detected the browser using MathJax's contextual menu and selecting the "About MathJax" item. The browser will be listed at the bottom.

Are you running your copy of MathJax locally? (That is did you download a copy and are using it from a file:// URL?) Firefox's same-origin policy for file// URLs prevents it from being able to access the web fonts from test/index.html. That may be the problem, here.

If not, then what version of MathJax are you using? Do you have the font problem when you view www.mathjax.org? If not, can you point us to a page that exhibits the problem you are having? Finally, do you have The STIX or MathJax fonts installed locally?

[dpl]

Davide, thanks so much, I feel a bit silly now. I had read about the same-origin issues, but not thoroughly enough to realize that this would hold for local copies as well - i simply assumed no sane program would be that strict... sorry for the hijack :(

[fred-wang]

Jesse Ruderman twitted a link to one of my recent blog post and someone responded on twitter that the rendering is slow with Firefox for Android Beta. I'm using MathJax's "isFirefox" to determine whether the Native MathML or MathJax's HTML-CSS output should be used on my blog. I suspect the sniffing does not work well with this version of Firefox and so the user is seeing the slower HTML-CSS rendering instead of Native MathML.

[bzbarsky]

Any progress on this? FirefoxOS is shipping, and MathJax sniffing will be broken there... We'd also like to remove the broken "netscape" thing from Gecko, but MathJax is what's holding us back from doing that.

[fred-wang]

Unfortunately, I don't think there is any plan to remove the sniffing right now (the functions are exposed as a public API).

Davide's changes for the latest release were

isFirefox: ((window.netscape != null || window.mozPaintCount != null) && document.ATTRIBUTE_NODE != null && !window.opera),

and

OTF web fonts used by default

Is sniffing window.mozPaintCount correct for the most recent versions of Firefox (I think here isGecko is really meant) or is something else needed? Do you have something to suggest for isMobile?

[bzbarsky]

I know what the current code looks like. It sort of kinda works in current desktop Firefox.

We are planning to remove ATTRIBUTE_NODE because it's gone in DOM4, we would like to remove window.netscape, and I personally would like to remove mozPaintCount. Since not everyone pulls from the CDN, doing so will break people unless the MathJax sniffing is fixed first and sufficient lead time happens.

If you really want to sniff for "Gecko" for some reason, why fake it with bogus object sniffing instead of just directly sniffing the UA string?

For isMobile, that depends on why you're detecting that boolean to start with. The FirefoxOS UA string is "Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0" and I believe the "Mobile" token is what you should be sniffing for if you really plan to sniff UA strings for an "isMobile" for some reason.

But seriously, the situation is totally broken and prevents new browser engines from entering the market. As in, MathJax is being actively bad for the web here. What would it take to get this sniffing removed completely?

[fred-wang]

The browser detection functions are essentially used:

1) In MathJax rendering code, to workaround layout bugs (including those from older browsers). 2) By MathJax, to choose the default output according to browser capabilities (e.g. MathML in IE+MathPlayer and HTML-CSS in other browsers) 3) By users, to let them override the default on his Website (say if the user wants to use MathML output for Firefox and Safari)

I think 1) could be avoided if we give up older browser versions (personally, I'm in favor of that but there is not any consensus... someone complained recently that MathJax no longer works with Firefox 3.6!) and if we report bugs upstream so that they can be fixed (that's what I've tried to do since I'm involved in the project).

However, I can't see how we can avoid 2) and 3) without having perfect and consistent native MathML implementations in all rendering engines. Since that's not a priority for browser vendors, I don't think it will happen anytime soon. From that point of view, MathJax is good for the Web because it provides a solution to a user community that needs to write mathematics on the Web. I agree, that's a pity that we have to use all sort of hacks to make the rendering of mathematical formulas work in browsers but at the moment we have no other options.

I don't know why Davide used object sniffing. Probably because this method was thought to be more reliable than UA string sniffing (some browsers claim to be a Mozilla agent if I remember correctly) but it's obviously not the case here. I guess the solution would be use the UA string for Gecko.

Davide?

[bzbarsky]

For (1), it seems like explicitly sniffing for the older browser versions is the right way to go for handling older browsers. For bugs that are still present in current UAs that doesn't help, of course. The right way to deal with those is for us to fix them on our side (in Gecko).

For (2) it doesn't seem like there needs to be sniffing for Firefox or Gecko, just for IE+MathPlayer.

For (3) how are API users supposed to make that decision and does it really depend on whatever objects are being detected (as opposed to, say, detecting sane MathML support)?

Maybe I wasn't clear. I think MathJax in general is wonderful thing for the web. I just think the way the sniffing here is done is completely broken and that aspect is actively bad for the web, because it puts up barriers to entry for things the sniffing mishandles.

Again, what should be sniffed depends on why the sniffing is being done. Which is why a generic "isFirefox" is not a good thing to do. If sniffing needs to happen, it's better to have fine-grained APIs like hasWhateverBug and supportsNativeMathML and whatnot.

[fred-wang]

(1) is currently the main work. I definitely need to list and check all the bugs/workarounds and report bugs upstream. I don't believe it's easy/possible to verify all these layout bugs other than by verifying the browser and version. But I need to analyze this in details.

For (2), I hope we will be able to default to Gecko's native MathML soon so determining Gecko will be needed. Perhaps it could be possible to use tests for advanced MathML features (like I did in my MathML acid3 test) to be sure that the browser has good enough native MathML.

For (3), the functions are in the public API. I said they are used to choose different output mode as that's the only usage I saw, but to be honest it's entirely possible that people use it differently. I suspect that a UA string sniffing would be fine for the usage I see. Again, I don't know why Davide chose to rely on object sniffing.

[pkra]

I would like to better understand this, too. If FF changes and MathJax breaks, then we need to adapt -- simple as that.

@dpvc could you weigh in?

[bzbarsky]

It's not just that. Right now the code in MathJax is actively preventing the removal of dead code like the window.netscape stuff in Firefox...

[pkra]

You're too kind. Leaving the browser sniffing vs feature detection debate aside, one way to read your OP is: FF will (sooner or later) remove this dead code and it just so happens that this will mean MathJax won't work properly anymore.

Since Firefox support is very important for us (>20% of CDN users use FF only bested by Chrome), we have to make sure we resolve this -- after all, Firefox does nothing wrong by following standards.

In an earlier comment you wrote about "falling back to standards". Could you elaborate what you have in mind?

[bzbarsky]

I think that's already happened, if I understand the "OTF web fonts used by default" bit above correctly.

But what I meant is that as of when I filed this bug if MathJax detected a browser that wasn't in some whitelist it just wouldn't work at all. The math wouldn't be displayed; instead it would display TeX markup, if I recall correctly. What I was suggesting should happen instead is that if the browser is not detected to be one of the ones known to be buggy in some way MathJax should default to assuming it supports things like CSS downloadable fonts, for example.

[pkra]

Thanks. You're right that we should find a solution for "unknown" browsers.

[fred-wang]

IIRC, there are not too many cases where MathJax has to workaround layout bugs in Gecko. And defaulting to Web fonts for unrecognized browsers fixed the most annoying failure. I think the isMobile function is only used to increase the timeout for Web font downloading (slower on mobile platforms).

Henri Sivonen reported a bug for FirefoxOS some time ago that would fix the problem: bundle math fonts. This will speed up the MathJax rendering and improve the rendering with Gecko's native MathML:

https://bugzilla.mozilla.org/show_bug.cgi?id=775060

There are similar bugs for Android: https://bugzilla.mozilla.org/show_bug.cgi?id=709159 https://code.google.com/p/android/issues/detail?id=36011

[dpvc]

Right now the code in MathJax is actively preventing the removal of dead code like the window.netscape stuff in Firefox..

Because the detection is based on window.netscape OR window.mozPaintCount, you can certainly get rid of window.netscape if you want (it is there for use with older versions of FireFox). I see you also want to get rid of mozPaintCount, so doing both would be a problem for us, but there is nothing stopping you from removing window.netscape (which was the only one we knew that you were getting rid of until today). The change has been in place since v2.1, which was released in October, so that has been around for quite a while.

if MathJax detected a browser that wasn't in some whitelist it just wouldn't work at all.

That is not the case, and never has been. MathJax does try to handle unknown browsers by making no assumptions about them. At the time MathJax was first written, assuming downloadable fonts would have been the wrong choice (as only a few supported it at the time), so the unknown browser gets image fonts, as I recall. It is probably time to revisit that. The browser-specific code is (in general) fine tuning the generic behavior.

I don't know why Davide chose to rely on object sniffing.

Because in my experience parsing user-agent strings is less reliable than object detection. My experience is certainly colored by the fact that it goes back to the early 1990's, when there was a lot of browser-spoofing in user agents because web sites enabled or disabled features based on the user agent. That is probably less prevalent now, but browsers often still give the user the ability to change the user-agent string, whereas they can't really change the objects that the browser provides.

While I certainly understand the desire to have feature detection rather than browser sniffing, there are some issues with that approach. Fred already mentioned that not everything can be readily detected (that is particularly true of IE bugs). Another issue is that MathJax gets configured when it is initially loaded, and that is in the document <head>, when the <body> is not yet available, so it is difficult to do feature detection at that point, as you can't really add the needed elements to the DOM yet. The alternative would be to delay configuration until the onload handler (or DOMContentLoaded), but this means that MathJax would have to delay loading its components, making the mathematics appear even slower than it currently does.

If everyone thinks user-agent parsing is better for Gecko-based browsers, then we can certainly go to that. (And yes, it should have been isGecko rather than isFirefox, and isWebKit rather than isSafari. My bad.)

[dpvc]

I think the isMobile function is only used to increase the timeout for Web font downloading (slower on mobile platforms).

I think it is also used in the menu code to add some close boxes to the menus (to make them work better for touch interfaces). The mobile UI needs to be improved, and that was just a patch until we got to work on that some more.

[bzbarsky]

so the unknown browser gets image fonts, as I recall.

That was certainly not happening on Wikipedia when I filed this bug. Users were just not getting any sane math display at all. See the screenshot at https://bug791526.bugzilla.mozilla.org/attachment.cgi?id=661569 for what happened instead (I was wrong; it wasn't Tex, but rather a generic error message).

Thank you for pointing out we can kill window.netscape now, assuming various MathJax consumers have upgraded.

In general, we are trying to remove all proprietary or nonstandard objects, so object-sniffing to detect "Gecko" is a losing proposition in the long run.

as you can't really add the needed elements to the DOM yet.

For what it's worth, you can add them as kids of <html> if needed....

[dpvc]

That was certainly not happening on Wikipedia when I filed this bug. Users were just not getting any sane math display at all.

MathJax has attempted to process the math, but has failed for some reason (not clear from the screen shot). One of the common causes of this is that one of the components has failed to load (or times out loading), which is more common on mobile devices. It is hard to tell without more investigation. The bug itself suggests that this was in a case where the TeX fonts didn't download, and STIX weren't allowed, and image fonts were disabled. So MathJax had no font data to work with, which is not a case that gets a lot of testing. We recently fixed a few issues with this situation (the default data was missing a structure that was required in some cases), so that might be what was underlying the error messages here.

In any case, it is not doing as you suggested, which was not attempting to process the math for unknown browsers and just leaving the TeX. This was MathJax trying to render the math, but failing.

[pkra]

Thanks for the many clarifications. Glad we could make headway on the actual bug :)

@dpvc what is the current situation wrt of user agent detection? Could we use it more reliably nowadays? It seems, Android browser still spoofs as Safari but then there's tools like detect.js which might help.

[Btw, I just checked out the FirefoxOS simulator for the first time. MathJax.org, math.SE render fine but mobile wikipedia does not work -- MathJax does not run, though I get TeX code when logged in. Seems like a bug with them.]

[bzbarsky]

Them being FirefoxOS or Wikipedia? Both are possible...

[pkra]

Since MathJax worked well with the FirefoxOS browser everywhere else, I'd suspect the Wikipedia app is the culprit. I couldn't figure out how to debug, but it didn't look like MathJax was loaded at all.

[fred-wang]

I've just spent some time to analyze more precisely where specific handling is done for Firefox. As previously said, there are not too many Gecko layout bugs contrary to other browsers. I assume the body is already available in the output modules, so in theory inserting elements in the DOM and measuring boxes would allow to detect bugs and address 1). At least, I see how to do that for MathML bugs. For 2) and related choices based on the browser (like custom messages, minimal versions or specific mobile interface) I think a UA string sniffing is fine. I believe the same is true for 3), whatever how people actually use it.

Davide: I know you're busy at the moment, but when you find time could you please explain the Gecko layout bugs so that I can check whether they are still valid, report them upstream and try to find a detection without sniffing.

./jax/output/HTML-CSS/jax.js

isFirefox/Firefox used when the Web fonts failed, to load to provide a custom message regarding "Web fonts on remote host".

ffVerticalAlignBug, AccentBug => needed to fix some box positioning?

./jax/output/HTML-CSS/imageFonts.js (not sure the module is really used now)

isFirefox/Firefox used to provide specific handling of some divs?

imgSpaceBug => I don't know what this bug is. Apparently, a span with a non-breaking is added when the boxes are placed? Perhaps to fix some spacing issues?

./jax/output/HTML-CSS/config.js

isFirefox/Firefox used to indicate that the minimal supported version is 3.0

./jax/output/SVG/autoload/annotation-xml.js

SVG.mathDiv.style.width = "auto"; // Firefox returns offsetWidth = 0 without this

=> Not sure what this bug, but no sniffing is used here.

./jax/output/NativeMML/jax.js

nMML.ffTableWidthBug => could be determined by checking the width of <mtable width="xxx">. Fixed in Gecko 13. nMML.forceReflow => this is essentially bug 491384, I guess. The issue was a bit random and several testcases have been proposed. I think the one I finally proposed in bug 731667 should be reliable. Alternatively, we could check for "_moz*" attributes in the DOM. Quentin is still working on it. nMML.spaceWidthBug => could perhaps be verified by measuring the width of an <mtable> with a wide <mspace> inside. Fixed in Gecko 20. nMML.tableSpacingBug => this can be determined by verifying the spaces between the cell bounding boxes when rowspacing/columnspacing is used. nMML.tableLabelBug => this can be determined by verifying the position of the label cell.

./config/MMLorHTML.js

isFirefox/Firefox is used to indicate that:

• the minimal supported version is 3.0
• the HTML output is preferred by default
• that MathML is supported

./config/default.js

isFirefox/Firefox is used to indicate that the HTML output is preferred by default.

./extensions/FontWarnings.js ./extensions/MathEvents.js ./extensions/v1.0-warning.js ./extensions/MathMenu.js

-moz-border-radius is used for backward compatibility

./extensions/HTML-CSS/handle-floats.js

// Two consecutive equations would end up side-by-side, so force a separator // (Needed by IE8, IE9, and Firefox, at least).

=> Not sure what this bug is. No sniffing done anyway.

./extensions/MathMenu.js

isFirefox/Firefox used to provide a custom warning message when the user switches to MathML

isFirefox/Firefox to modify mouseover/mousedown event handling on mobile platforms.

./extensions/TeX/mathchoice.js

// Firefox doesn't correctly handle a span with a negatively sized content, // so move marginLeft to main span (this is a hack to get \iiiint to work). // FIXME: This is a symptom of a more general problem with Firefox, and // there probably needs to be a more general solution (e.g., modifying // HTMLhandleSpace() to get the width and adjust the right margin to // compensate for negative-width contents)

=> no sniffing

./MathJax.js

// Firefox3 gives "Security error" for missing files, so // can't distinguish that from OK files on remote servers. // or OK files in different directory from local files.

=> no sniffing

IIUC, isFirefox/Firefox is also used to:

• modify browser.version for older versions.
• determine isMobile

---

Finally, two old bugs that I never reported to Bugzilla (are they still valid?):

https://github.com/mathjax/MathJax/issues/231 https://github.com/mathjax/MathJax/issues/212

[dpvc]

I sort of recall that the versions of Wikipedia pages for mobile devices don't include MathJax. But I haven't checked.

[fred-wang]

f0aea1669d6649c92eca63fdf007fb43f3ba1da1

I've replaced the object sniffing for Firefox by UA string sniffing. I've used what was in prototype.js (http://prototypejs.org/download/) that is the substring "Gecko" is present but not "KHTML". This has been used since May 1, 2007 ; so that should work for Firefox >= 3 and in particular the versions we support. For "Firefox", isMobile now includes the verification of the "Mobile" token (I've kept the former verifications too, just in case).

I think this change could be taken for the next release. I'll see later how much I can fix regarding 1).

[pkra]

Just FYI, I reported the MathJax on wikipedia mobile bug upstream.

[dpvc]

OK, I've merged your sniffing branch to develop.

[fred-wang]

I've just created an experimental branch to do "feature detection" for MathML bugs: https://github.com/fred-wang/MathJax/tree/mathml-feature-detect

@dpvc I'm wondering what is exactly the problem with the incorrect width of <math>? I see that we use offsetWidth and scrollWidth which may not give correct values (respectively 0 and rounded in Gecko) but why don't we just use getBoundingClientRect, which gives the accurate value?

[pkra]

@fred-wang is there a description somewhere what your new branch is supposed to be doing?

[fred-wang]

See Boris' blog post above: https://github.com/mathjax/MathJax/issues/317#issuecomment-8772223

The branch tries to implement "feature detection" for the MathML support in order to apply the appropriate workarounds. So for example instead of verifying the browser and version to decide whether it supports the "mfrac" element, we just insert an mfrac element and check that the numerator is above the denominator. In theory, this should be more reliable than having to deal with browser sniffing, reading version in UA string and keeping the list up to date... Also, when a new release of Firefox fixes a MathML bug or if Opera removes MathML support in version 15, we don't have to wait for the next MathJax release to enable or disable the workarounds.

However, there are also some issues to consider... that's why the branch is experimental :-). For example other browser bugs/inconsistencies may give false test result and thus make the feature detection incorrect. Also that does not completely eliminate browser sniffing, because you sometimes need to know the browser and version to decide which workaround to apply (like the one for mo@lspace/rspace that works only for WebKit flexbox-based MathML implementation). So again, I don't think that would be possible to completely remove browser sniffing until browsers improve their MathML support.

I'm investigating if it would be possible to integrate jqmath's ideas in the NativeMML to workaround the lack of MathML support while still keeping a fast rendering. Since there are many MathML elements and the MathML support vary a lot between browsers, it would become even harder to maintain the list of supported features and bugs (Davide mentioned that he would hate to have to maintain that list, when I suggested an automatic selection of the rendering mode according to browser capabilities and MathML elements used on the page). So having this feature detection would be helpful, here.