Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
I also get this effect. Moreover, when this is happening, I sometimes think I see the preview region flickering as I type, as if it were trying to update but then reverting to the old version.
Browser details: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Same! I thought that this was an opera-only bug, so I wasn't going to rock the boat; but yes, it is really annoying.
I've seen this too.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090909 Fedora/3.5.3-1.fc11 Firefox/3.5.3
I should note that this didn't happen with jsMath (one of the reasons why I liked jsMath!)
Also, jsMath didn't lag as much. I often have to turn off the preview to be able to type at any reasonable speed.
Huh. My experience is slightly different. I agree that this bug for me started shortly after we switched to mathJax. However, my experience with the timing issues was that jsMath sometimes made my characters take noticeable time to appear in the window where I was formatting my answer. This was very frustrating, because I would get half a line typed before seeing my typos show up. With MathJax, the preview often lags noticeably behind my typing, or stops updating at all, but I always see my characters appear in the edit window immediately. I think the latter is a more graceful way to fail, if we cannot avoid failure.
@David:
Sure, but having the preview stop working the way the MathJax preview does is substantially worse than the lag (and strangely enough, I had the opposite experience. MathJax seems to lag way harder than jsMath).
MathJax per se we'll just have to watch and wait --- I'm not sure how much, if any, development time is going into profiling and optimizing MathJax. (That said, Chrome has some nifty profiling tools built in, and potentially anyone could track down bottlenecks.)
On the other, almost certainly we can work around this. I'm guessing that rather than sending the entire draft through the markdown parser and thence through mathjax, we could, in JavaScript, cut up the draft into paragraphs and present the previews of each in separate divs. Maybe this would reduce the load.
Also --- for this sort of issue modern browsers are really important. It might not seem that much has changed in the browser world recently, but JavaScript engines has been improving dramatically. If the preview update is a problem for you, make sure you're running the latest version of your preferred browser.
@Scott: The bugginess of MathJax in the preview is an implementation issue. The speed issue is substantially less important and also substantially harder to deal with (if it could even be done).
The JavaScript console in google chrome (there are equivalents for other browsers) does a pretty good job of showing what's wrong. Perhaps someone can reproduce the problem and report if any errors show up in the console. It would be good to report this to the MathJax people, but they'll need something concrete to go on.
I got excited because I thought I experienced this bug and tracked down the problem. Unfortunately, it turns out my computer was just switching wireless networks, so when the browser tried to fetch some MathJax file, it got the AirBears login page and got extremely confused. If anybody can produce some kind of debuging data, it would be much appreciated.
@Harry: Am I correct to assume that you mean that MathJax lags harder in the preview? This is because MathJax doesn't (yet) have a cache, whereas jsMath does. In reading material on MO, it's rare that exactly the same formula shows up a huge number of times, so MathJax should be as fast or faster than jsMath.
1 to 11 of 11