User-visible warning for disconnected/not saving state

[cben]

Yesterday I pushed broken CM/firepad combo such that pages loaded, you could edit but edits weren't saved! There was no user-visible indication this is the case.
But simply being offline gives a similar result.

• Visible indication that firebase is offline and not syncing.
• Close the loop verifying edits really made it into firebase (REST api?), such that unsaved edits — for any reason — for several seconds give the warning.
  It's not enough to check firepad's idea of version made it to the server; I suspect in this case there was an exception early in firepad such that it's version. Ideal might be comparing full text (not too frequently)?

Local storage backup wouldn't hurt too, but that's another story.

[cben]

Asked for advice at firepad group: https://groups.google.com/forum/#!topic/firepad-io/s1aTZXZniAM

[cben]

This is partially implemented, and works very nicely when typing and when internet goes offline/online.
But I haven't yet tested how it behaves in the face of bugs like #85 — I'm relying on Firepad knowing when it's synced but there might be a situation when Firepad itself isn't aware there was a change in the editor.
I think I should use headless firepad API to periodically (e.g. once a minute) do a clean text reconstruction of what is currently saved in firebase and compare to the editor.
Also, cross-compare with Firebase's connected status for more useful reports e.g. "unsaved because offline" vs "online but not saved — BUG?"...

[cben]

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)

• The status indication overlaps the upper part of the header line, interfering with clicking stuff like [bugs]. e0f1b36 fixed this for most of the width, but the transparent "saved" or "done" text is still there, making it very confusing why you sometimes can't click the underlying [bugs] link (if your window width is such that they overlap).
• On IE8, not only the transitions don't animate (which I expected an am fine with) but opacity doesn't work at all, so "done" and "saved" texts are visible all the time.

I'm somewhat fond of the fading out to "done" / "saved" so looking at solutions that don't give them up. http://viget.com/inspire/css-pointer-events-and-a-pure-css3-animating-tooltip and http://www.greywyvern.com/?post=337 sound promising...

[cben]

BTW, pointer-events: none initially looked like a good direction, except it doesn't work on IE<11,
and also didn't work on my Chrome until I set visibility: hidden on #status_container.
Setting that also helped visibility transition on status to work, and visibility support is robust so I'm going with only that.

[cben]

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; it seems firebase-debug.js not only reports but also tolerates exceptions better, and I only managed to reproduce with the non-debug firepad.js)

[cben]

• 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 much this happened (and retroactively merge?).

[cben]

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