Beni Cherniavsky-Paskin

Bah. What I pushed was somewhat broken (interleaved for extra karma with pushing a an extremely sloppy "redesign" breaking the [New document] button and [the whole display on IE](https://github.com/cben/mathdown/commit/dc82eab27a8eb837e547989c6c7e99a5e23ba2a6)) -...

BTW, `pointer-events: none` initially looked like a good direction, except it doesn't work on IE

Back to the real goal: would current indication based on firepad's `synced` event catch #85? => NO. (Reproducing #85 took some effort. Going back to the buggy CM-MJ wasn't enough;...

- [ ] If we detect this kind of error, report it somehow in firebase (with full base version + doc text?) so future analysis can at least know how...

Aha moment! After `sendOperation() called with invalid operation.`, firepad goes back to report that it's "synced". I can — and should — fix this upstream.

Progress: Headless firepad works. (For some reason it didn't for ~ a day when I initially played in the JS console but now it works both from script and console)...

Oh, dev consoles leak a lot as well. Quickly reach hundreds of megabytes. This is easily explained by my very verbose logging, including JS objects and DOM elements. Chrome and...

https://groups.google.com/forum/#!topic/firebase-talk/AEDekJ_B480 is interesting. It's likely that `new Firepad.Headless()` registers new firebase callbacks that never go away (and keep the Headless itself alive and updating...)

Just reducing CPU usage to say once/minute is not good enough. Consider a person with 30 mathdown tabs — now one of the tabs wakes up (and largely swaps in)...

Using heap profiling on the [~100K document](http://mathdown.net/?doc=CS3X9O9FQgI). Without headless checking it's 70MB on load, 170MB after renderingm math. With checking, after being open for 1000s, it's 360MB. During 50s heap...