User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20120915201302 Steps to reproduce: Installed Nightly 64 bit, then opened https://www.edx.org/courses/MITx/6.002x/2012_Fall/courseware/Week_1/Circuit_Analysis_Toolchest/ Actual results: All the math was displayed as [Math Processing Error] in red Expected results: Math should have displayed properly

This webpage is surely private, I can't access. Can you provide a public page, please?

Erm... The math is broken everywhere. You can open any wikipedia page with math,i.e. http://en.wikipedia.org/wiki/Simple_linear_regression and you will see math processing error. Just don't forget to switch wikipedia math rendering to "MathJax (experimental; best for most browsers)".

Reproduced at the Wikipedia page with Nightly 18.0a1 20120918030553 Linux x86_64. Works with 16.0b2.

I reproduced too. There is this error in the console: Error: TypeError: MathJax.InputJax.TeX.Definitions.macros is undefined Source File: http://bits.wikimedia.org/static-1.20wmf11/extensions/Math/modules/MathJax/jax/output/HTML-CSS/jax.js Line: 15 Mozregression range: m-c good=2012-08-23 bad=2012-08-24 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5650196a8c7d&tochange=1c0ac073dc65 The changelog is pretty huge, bissecting needed.

Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/16e1ff49a6a5 Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17 Firefox/17.0a1 ID:20120823114047 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/c1e3da499d87 Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17 Firefox/17.0a1 ID:20120823114645 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=16e1ff49a6a5&tochange=c1e3da499d87 Suspected : Bug 757046

Thanks for the bisect. :)

That's somewhat odd. I see no mention of enablePrivilege in the MathJAX source code. And the examples at http://www.mathjax.org/demos/tex-samples/ work fine for me in a nightly...

I will try to check if I can reproduce this bug and report it to the MathJax team. Probably not related, but see this issue on the MathJax tracker: https://github.com/mathjax/MathJax/issues/256

OK, I've just tried with a fresh nightly build. First I didn't get the errors on the page mentioned in comment 2 with local fonts installed. But when I uninstall the MathJax fonts, I get "Can't find a valid font using [TeX]" and after a moment, the [Math Processing Error] errors appear. On mathjax.org, I don't get the errors but STIX fonts are used instead. Also, I don't have the errors with the MathML or SVG output modes. So I suspect the problem is with downloadable fonts. When the MathJax fonts are not installed on your system and the Website is not configured to fallback to STIX or image fonts (apparently that's the case in Wikipedia), then you get the [Math Processing Error]. Have there been some changes on the security policy regarding downloadable fonts? Or perhaps MathJax uses enablePrivilege to workaround it?

> Have there been some changes on the security policy regarding downloadable fonts? There should not have been, in the checkin range when this bug appeared... > Or perhaps MathJax uses enablePrivilege to workaround it? Again, grepping a download of MathJax for enablePrivilege shows nothing over here. So something weird is going on.

OH! I know what happened. MathJax does all sorts of broken-ass browser sniffing. And in the case when it doesn't sniff a known browser it falls back to "Oh, just break shit" as opposed to "Oh, use standards stuff". The patch for bug 757046 effectively removed the code that ended up defining window.netscape. And MathJax tests for window.netscape as part of its test for "is Firefox". So now it decides the browser is not Firefox, and falls back to "Oh, just break shit". I filed https://github.com/mathjax/MathJax/issues/317

In the short term we may want to put window.netscape back for now, because getting everyone on the web to update MathJax is a pain.

And in the long term, what MathJax is doing is locking out new browsers and holding back the web...

OK, I see. So that's the same issue you raised once in the past. MathJax's philosophy is that "it just works" without plugin or font installations. For that purpose it uses fallbacks like Web fonts or images... but ironically, this bad browser sniffing just makes everything fail. I agree with you that MathJax should really focus on newest browsers and remove this image fallback. I'll try to convince Davide. BTW, people are encouraged to use the MathJax's CDN and most people do that. The upgrade is automatic in that case.

> I agree with you that MathJax should really focus on newest browsers and remove this > image fallback. Well, or make it work. Or something. Wikipedia doesn't seem to use the CDN, though I could be wrong about its twisty maze of lazy-loading goop.

(In reply to Boris Zbarsky (:bz) from comment #11) > The patch for bug 757046 effectively removed the code that ended up defining > window.netscape. And MathJax tests for window.netscape as part of its test > for "is Firefox". So now it decides the browser is not Firefox, and falls > back to "Oh, just break shit". Boooo web compatibility issue caused by code removal. Let's add it back in, if it isn't too much work.

OK, Bugzilla, you suck. I did of course not mean to remove the tracking+ flags. But refreshing the page (been open a while) and then hitting "Save changes" to get myself in the CC seems to sometimes change random fields back to previous values. :-\ Alex: I'd put the +'s back, but I can't. Sorry.

So Davide seems to agree that it's best to use the Web fonts in general rather than the image fallback. His detection method (for other uses) is now ((window.netscape != null || window.mozPaintCount != null) && document.ATTRIBUTE_NODE != null && !window.opera)

I fully expect ATTRIBUTE_NODE to die one day. Same with mozPaintCount. But I'm happy to discuss that over in the MathJax bug.

Is there a reliable and standards compliant way to detect firefox? Why use things like: ((window.netscape != null || window.mozPaintCount != null) && document.ATTRIBUTE_NODE != null && !window.opera) Also, this comment in mathjax tracker is brilliant: 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. ;)

(In reply to Boris Zbarsky (:bz) from comment #19) > I fully expect ATTRIBUTE_NODE to die one day. Same with mozPaintCount. > > But I'm happy to discuss that over in the MathJax bug. Yes, my comment was really to say that it's maybe not necessary to restore window.netscape, at least if that's only not to break MathJax. The sniffing test will certainly break again in the future, but at least the most serious issue with Web fonts not used when they can won't happen anymore.

> Yes, my comment was really to say that it's maybe not necessary to restore window.netscape A minimal requirement for not restoring it is that Wikipedia and the other site reported in this bug not be broken, yes? Once that happens, we can talk! ;) > Is there a reliable and standards compliant way to detect firefox? Sure, like checking the UA string for "Gecko/". But usually once you start worrying about "Firefox" as opposed to "specific Firefox versions", you're doing it wrong...

Comment on attachment 665439 [details] [diff] [review] Temporarily add the |netscape.security| object back in to fix broken browser detection. v1 r=me I wonder whether it makes sense to make the .netscape getter warn about the property being deprecated and about to go away. Followup on that?

(In reply to Boris Zbarsky (:bz) from comment #24) > Comment on attachment 665439 [details] [diff] [review] > Temporarily add the |netscape.security| object back in to fix broken browser > detection. v1 > > r=me > > I wonder whether it makes sense to make the .netscape getter warn about the > property being deprecated and about to go away. Followup on that? bug 794923.

Comment on attachment 665439 [details] [diff] [review] Temporarily add the |netscape.security| object back in to fix broken browser detection. v1 Arg, m-i is closed. Anyway, flagging for aurora approval per comment 16. [Approval Request Comment] Bug caused by (feature/regressing bug #): 757046 User impact if declined: web regressions Testing completed (on m-c, etc.): none Risk to taking this patch (and alternatives if risky): extremely low risk. Just moving our early return slightly later. String or UUID changes made by this patch: None

Comment on attachment 665439 [details] [diff] [review] Temporarily add the |netscape.security| object back in to fix broken browser detection. v1 low risk, approving for Aurora uplift.

Math on the Wikipedia page works with MathJax on Fx 17.0b6 20121113065533 Linux-x86_64.