Indication of whether a post actually has saved

(Clay Heaton) #1

I’ve had 3-4 instances (over the past 6 months) when I’ve written a long post, clicked either “Create Topic” or “Reply,” and felt that the post saved to the database because I was instantly shown it in situ in the Discourse interface. However, upon browsing away from the post, I discovered that it actually hadn’t saved. In fact, it wasn’t present at all. Usually, then clicking Reply or New Topic will show me a partial version of the post I wrote.

While I haven’t been able to reproduce the problem and I recognize that it likely is because my Internet connection dropped out or otherwise was flaky, it was incredibly frustrating to lose the bulk of what I wrote. Had I known that the posts actually did not save, I could have copied the text from them to a text editor and then tried again.

It would be nice to have some type of indication (or something more obvious?) that a post I just wrote and tried to submit actually was captured by the system. During editing, the “saved” text appears at the bottom of the edit panel. However, unless I’m completely missing it, there doesn’t seem to be any corollary for when you actually click “Create Topic” or “Reply.”

Post won't save (text included)
(Jeff Atwood) #2

Well, saved at the bottom means a draft was saved. This is during editing. After the post is submitted the draft is deleted.

I have never seen what you are describing, nor have I heard it reported elsewhere. Even on flaky mobile connections. Is it specific to a browser? Does it happen on mobile? Does it happen on just one Discourse or all of them? Can you provide repro steps?

Not sure if @sam has anything else to add as far as potential troubleshooting.

(Clay Heaton) #3

Well, it’s only happened 5-6 times over the past 6 months or so. I’ve tried to reproduce it purposefully, but I’ve never been successful. I’ve looked at the error logs following incidents and not seen anything. I use the latest Safari on the latest OS X about 95% of the time, so it’s likely it happened in that environment. It’s only happened on a Discourse that I get to through a VPN connection. The VPN sometimes is flaky, which is why I’m sort of assuming that it is related to a flaky network connection.

I’ll try to see if I can develop a repo case.

From the UX standpoint, I I know that the contract of trust with the user relies on lack of data loss. While this is explicit during the editing stage (with draft saving), it’s not at the posting stage. Perhaps an equally inconspicuous ‘saved’ indication at the posting stage would support that trust.

While it’s been very frustrating when this has happened to me, I’m a fan/follower of Discourse and it’s not going to deter me from using the software. I worry, however, about people at my company who are increasingly using the system. Being different and new, it hasn’t been easy to get them to adopt Discourse. For many of them, if they suffer data loss, I suspect they’ll walk away and never look back.

This actually brings something to mind… each time that I’ve experienced the problem, the latest saved draft was quite a bit earlier than the post that I tried to save – maybe even 5-10 minutes (or more) earlier. The reason I know this is because after I’ve submitted the post – thinking that it saved, and gone to reply to (or simply create) another post, the edit box has been populated with the earlier saved draft, where most of my original post is missing.

The last time it happened to me, I clicked to post my message and noticed a spelling error 3-4 seconds later. I went to click the edit pencil icon, but it wasn’t there. Based on previous experience, that made me realize there likely was a problem, so I copied the text of my post and refreshed the page. As I expected, the post had not actually saved. I clicked reply again, pasted the text in and saved – it posted and saved immediately without further issue.

(Dave McClure) #4

I think I may have seen this once or twice in my tenure here, but I can’t say for sure.

One thing to consider here too is a more prominent ‘not saved yet’ indicator in the composer window if the draft hasn’t successfully saved in the past N minutes.

(Tobias Eigen) #5

This has happened to me too, a couple of times and completely randomly it seems, so I haven’t bothered reporting it. I also had the weird experience that it appears to be saved but then is not actually there. So when I write a long post I tend to copy it to my clipboard before hitting submit. Old habits die hard.

I have a suspicion - not verified - that it happens when I spend a long time on a post and click around the discourse site, looking at admin and preferences and about page, and then when I save it doesn’t actually save even though it looks like it did.

(Kane York) #6

There was a conflict with two editors being on the preferences page - maybe it’s that problem again?

(Tobias Eigen) #7

could be - I did just have another interesting issue… I was in a topic and then opened the preferences of a user, and the second half of my post disappeared.

(mountain) #8

This is eerily familiar to my problem here. Sounds like the exact same. I explain more here and here in the same topic.

Problems with automatic draft saves and the cooked post showing a previous auto-save of the post while I was writing it. It got so bad for me I had a massive hunch the behavior was going to happen so I saved my completed text and then saved the post. Sure enough, it reverted to an earlier draft while I was typing it.

(Clay Heaton) #9

That sounds like the exact same problem. It’s very frustrating… I’m not a ninja-editor, most of the time, so I’m not sure that the problem always has to occur during the brief ninja-edit window. In so much as this is a very serious problem, I’ll bang on it tomorrow to see if I can come up with a consistent repro case.

(mountain) #10

The problem is there are no specific repro steps. To my viewpoint (as I experienced it) I was using the ui as expected. It would do the behavior randomly.

I can say, however, that after cleaning my Chrome’s cache and disabling it, the problem stopped. Or, I haven’t had it happen ever since I first reported it in the topic I linked above. Previously, as I reported, I was getting the behavior constantly due to my special case (using laptop that wasn’t cleaned in a long time, usually use workstation that is able to handle any size Chrome cache).

(Clay Heaton) #11

Hmm, I almost never use Chrome, so that’s probably not the issue for me. If it’s a cache issue, then it must be cross-browser and/or something in the webkit guts, still remaining in Chrome, that is causing the problem. I clear my cache somewhat regularly, however, just to make sure that it isn’t loaded with crap while I’m developing other web-based stuff.

(mountain) #12

Aye, I figured. You mentioned an internet connection problem, yeah? My little pet hypothesis to this conundrum is if the connection stalls at all, it might play a part during the auto-saving and the actual button-click to manually save the post.

I know this because I have tested this laptop. When it gets nutty with the cache (Waiting for cache…) my connection does slow a bit. I ping in the command prompt while it chokes on the cache. Here is the difference:


Pinging [2607:f8b0:4009:80b::200e] with 32 bytes of data:
Reply from 2607:f8b0:4009:80b::200e: time=52ms
Reply from 2607:f8b0:4009:80b::200e: time=37ms
Reply from 2607:f8b0:4009:80b::200e: time=37ms
Reply from 2607:f8b0:4009:80b::200e: time=40ms

Ping statistics for 2607:f8b0:4009:80b::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 37ms, Maximum = 52ms, Average = 41ms


Pinging [2607:f8b0:4009:80b::200e] with 32 bytes of data:
Reply from 2607:f8b0:4009:80b::200e: time=37ms
Reply from 2607:f8b0:4009:80b::200e: time=36ms
Reply from 2607:f8b0:4009:80b::200e: time=37ms
Reply from 2607:f8b0:4009:80b::200e: time=37ms

Ping statistics for 2607:f8b0:4009:80b::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 37ms, Average = 36ms

The top one is while it chokes on the cache.  Bottom is when it isn't.  If those extra ms increments count, well, hrrm...

`*takes off his tin foil hat*`

(Sam Saffron) #13

We should change the styling of posts we dump on the page to indicate they are still saving and remove styling once changed.

The main reason something like this would happen is if your connection was stalled and it took client a huge amount of time to hear back from the server.

(Clay Heaton) #14

Something like that would be great as a failsafe… just some indication that “Hey! Your post hasn’t saved yet! Proceed with caution!”

(mountain) #15

If this will help the “baked post isn’t the same as what I actually saved” problem I and others have been having, I am all for it.

Because it just happened to me again here. I paused typing after the positive comment. Then typed more on notification settings in user preferences. I replied/saved and it only showed that single line (“I got one notification so far. It looks great.”). It didn’t save after I paused then typed the second part of my post. I just had to go back and add my second thought that didn’t save.

(Jeff Atwood) #16

That has absolutely no relation to this whatsoever.

(mountain) #17

It appears that it is related if any kind of stalling connection doesn’t save what was written before a user hits ‘reply’ to post. Since neither @clay’s problem or my own has any kind of solid repro steps then it’s safe to assume they might be related as we both have the occasional stalling connection, for whatever reason it may be.

(Jeff Atwood) #18

No. I have had the partial baking problem before, myself. Your post is saved, and clicking wrench, rebuild HTML, shows the correct content every time (or editing the post, the edit content is more complete.)

Basically there is a failed baking of the post from raw to HTML. Rebaking or editing shows all the content, it was all saved.

Read the OP and it is nothing like this.

(mountain) #19

Since I cannot rebake my own posts I am not inclined to immediately jump onto that as a conclusion. Also, I am not easily assured of that since that implies the content is in the database, but the failed baking only regards the javascript or at least the uppermost layer that handles the ui. The original wording would need to be in the database for someone to rebake. My original content was never saved so a rebake could never happen because the content isn’t there to begin with to bake.

Hence, my problem stems from the same outcome described in the OP. Exactly the same, described as I have experienced it. As in:

Exactly that. There’s more to the problem than what is described in the OP.

(Jeff Atwood) #20

Read more closely. You can edit your post, yes? Is there a difference between what you see when you edit your post, and when you refresh the page?

Different problem entirely.