This happens every now and then. I write a reply and hit Reply. The panel which contains my reply collapses and turns into a blue bar with the word “Saving” written in large friendly letters followed by a spinner. But it never saves, just keeps spinning. I can’t go back, I can’t copy my reply, I can’t even find it when I examine the bar using the Chrome Dev Tools Inspector or whatever its called. The reply is gone and must be re-written.
The forum should leave the reply on screen, in a copyable form, until saving succeeds.
I may have had the same experience. A telltale sign that something is amiss is when the draft isn’t saving, or my other discuss tabs aren’t loading or have an error. In that case, if my post is important or I don’t want to lose it, I save it in a text file. Annoying I know.
i’d be more inclined to lean towards some sort of JS blocker… I’ve used these forums (and other Discourse forums) in a location with a HIGHLY unstable network connection, and while I’ve had issues posting, I’ve never seen anything like the behavior described…
I’m running uBlock Origin and Privacy Badger. But this reply-eating behavior is rare, so I doubt the blockers are related.
Yes, it’s fiber, no issues detected at the time this happens.
I usually ctrl+a & ctrl+c before posting, but sometimes one forgets, or sometimes one is too optimistic about one’s immediate future.
I’m running Google Chrome v77, no unusual settings. This issue popped up sporadically (but rarely) over the last year or two, so it’s not related to any specific version. It’s also not a big deal, since its rare, but when it does happen, and you just wrote a long reply…
By the way, in my screenshot above there is an “x” visible in the blue bar, and next to it there was a “popup” icon to expand the bar (which I failed to include in the screenshot). Clicking the “x” works (IIRC it asked me whether I’m sure I wanted to close it), but clicking the popup icon didn’t expand the bar.
Whatever the exact cause of the problem is, the fact is that the reply gets removed from the screen before the saving routine returns success, and this is a bad design choice, so I’ll report this upstream.