@driess mentions losing data from Phabricator when submitting forms if the machine is offline (i.e., no connection to the internet). We try pretty hard not to lose data and the "saved draft" system generally seems effective, but since it relies on saving data to the server it can't do much if the browser is offline.

I can't immediately figure out how to lose data in the main comment form by going offline (I can press "back" and the text is preserved -- this might only be bfcache browsers, though?), but you can lose data in inline comments by bringing up the comment box, bringing down your server, and then submitting the comment.

We should poke at this a bit more throughly and identify any other ways that data can be lost.

In general, we should improve status display, request shaping, and error handling behavior for async requests -- see also {T430}. We mostly just assume they'll work quickly right now (which, to the strategy's credit, does seem to be largely true) but isn't true in reasonable cases like huge diffs vs AWS micro instances and yanked internet.

Some specific ways we can fix these sorts of issues, specifically:

• We should fix the inline comment JS error handling to fail gracefully if it encounters an error.
• We could workflow=true the comment forms and handle the failure explicitly in JS if there are non-bfcache browsers or other issues with recovering from connection failure by pressing "back".
• We could use localstorage to save drafts, although this means we need to add some complexity around deciding which draft to trust if there are local and server versions available.