Each draft is strongly associated with the composer via a unique id. This only roles forward.
What do you mean by this?
I basically mean that if there is a race … and two composers are replying to the same topic for the same user … only 1 ever wins. Each time we save an owner is picked.
Alright @sam, I’ve got steps to reproduce. No idea if this is related to OP’s original issue (since this conversation has veered off a bit), but either way here’s what I have. Basically, if you open tab 2 but continue typing in tab 1 before tab 2 has fully loaded the new page gets into a bad state. If you continue typing in tab 1 while tab 2 is still loading, tab 2 will load the draft from tab 1 as it was when the page was opened, but you will still be able to edit in tab 2 even after tab 1 has saved additional changes (thus overwriting those changes). Here are steps to reproduce:
- Open topic A and start composing a reply.
- Stop typing so the draft is saved.
- Open topic A in a new tab (Duplicate tab or right/center clicking the topic title is the easiest way to reproduce since they have to do a full page load and are therefore slower).
- Immediately continue composing the reply in tab 1, before tab 2 has finished loading.
- Stop typing so the the draft is saved again (this will succeed, as expected).
- Go to tab 2 and type in the composer.
- Stop typing. The draft will be saved even though the warning should appear. This will overwrite all the additional changes you made in tab 1 from step #4. (If you get the warning as expected you probably waited too long to start typing in step #4.) Note that at this point you also cannot type in tab 1 again without refreshing that tab.
Note that in step #4, you don’t actually need to stop typing and save a draft before tab 2 finishes loading. Just starting to type is what gets everything in a bad state. It’s actually not unreasonable to open a duplicate tab in the background to check stuff later and continue typing in tab 1 in the meantime. But doing that too quickly will get the tabs in a bad state and allow you to accidentally overwrite what you added in tab 1. Of course, minimizing the composer also saves a draft, so once you get into this bad state just minimizing the composer in tab 2 to get it out of your way will overwrite your latest draft from tab 1.
At this point if you go back to tab 1 where you originally were composing your message, you can no longer type and will get the warning that should have shown up in tab 2. If you realize that your draft was lost you can of course copy the contents of the composer from tab 1. But if you didn’t realize and reload the page (following the instructions of the warning), you will lose the changes you made and have no way of getting them back.
Let me know if you still have trouble reproducing the issue with those steps. I can reproduce the issue pretty consistently following those steps (occasionally switching to new topics to get fresh drafts), so hopefully that’s enough information.
OK, I have a fix here:
Thank you so much for the repro here it was spectacular and helped me isolate the issue quickly.
I feel like I had a bit of a hand-wavy answer to how we keep track of draft versions, I think it boils down to me being a bit too naive and fancy in my algorithm. That is a deadly combo. The new algorithm is far easier to explain.
Whenever the client saves a draft, it tells the server what “sequence number it has”
If the sequence number matches, server will increase the sequence number by 1 and give it back to the client (our new sequence number)
If the sequence number does not match, the server will tell the client there is a conflict and not save the draft
On page reload / load the server tell the client what the current sequence number is
My previous implementation was too fancy, it tried avoiding increasing the sequence number under lots of conditions by tracking owner of a sequence. Your test case showed how bad that is and how it can cause content loss.
This should be live on meta, let me know if you can find more edges in this system.
That’s quite a compliment @seanblue you should be proud of this one
facing the same issue here in meta:
- I opened a composer, and write the title.
- to take an screenshot for this bug, I changed it from a “new topic” to “a new message”.
- I cancel the topic (i.e. the message) as I couldn’t change it back into a topic,
- I started a new topic.
a warning was shown incorrectly (since I already canceled the message):
now even when I chose to “abandon it”, every 10-20 seconds I got this message:
while there is no other tab.
this only happens if I change from a topic to a message. it seems the cancellation of a massage doesn’t really cancel it.
This requires quite a bit of work, shuffling between tabs in the browser but yeah … the abandon is certainly failing to abandon in this case, we should fix that.
I’ve been getting it in a completely different context, and wrong.
Always on mobile, I’ve reproduced it with both Brave and Duckduckgo on Android, and had a user tell me they’ve seen it with Android Chrome. It’s not 100% reproducible, but probably 50 to 80%.
- Start a reply.
- Switch to a different app (typically Firefox Focus, but not always) select some text to copy from there.
- Return to the Discourse app.
- Bam. “Draft is being edited…”
There is no other window. Hitting page reload fixes it. Ignoring it can result in double posts (both apparently complete). I’ve been seeing it for a while. Yesterday I had a double post, because the “Draft” message came up only as I was finishing. Running 2.6.0.beta1 Discourse.
I know you only support Chrome on Android, and I avoid that browser for more privacy enforcing ones. But DDG and Brave are, I believe, basically wrapped Chrome. I never had this issue when I was using Firefox on Android for Discourse, but there were plenty of other issues, mostly cosmetic.
Do you have any thoughts on the above, @sam?
Honestly… not too many, will give it a shot on my ancient android, hopefully it can make this happen.
Recently this message has been appearing for no apparent reason on our forum, is anyone else experiencing this?
I’m also seeing this. It’s only a recent issue
We just upgraded from 2.8.0beta7 to 2.8.0beta11 and have already received several reports of this happening since.
I use a self-hosted forum as a wiki knowledge base. I usually edit the topic several times a month (I’m the only one in the community who edits).
At first, the site was running in standard configuration and everything was fine. This message did not appear for no reason.
Then I connected the site to an external proxy Nginx, so that the traffic became HTTPS protected. And from that moment at least 1 time per day I see this message that the draft is being edited in another window. There are no other windows, nor are there any users editing the topic.
It seems to me that connection to HTTPS proxy caused these messages. Unfortunately, I can’t show all external Nginx settings, because this is forbidden by internal rules.
Maybe this information will help admins or developers to look away from Discourse and look towards the network settings of the environment.
I am getting this error also according to various users, and I am running 2.9.0.beta5.
We’re still seeing the
this draft is being edited in another window warning even when those posts are not being edited elsewhere. Many users are saying it happens on mobile, tho for me personally it happens mostly on desktop (I rarely post via mobile). I always thought it was because I have tabs of the forums open on both my iPad and iPhone as well (although these devices are always on their lock screens when I am typing a reply on my Mac).
FYI we have some plans to improve this situation especially for cross device and cross tab edits. @pmusaraj is worked recently on some specification in this area.
I actually saw one of these yesterday … I think the repro may be:
- Edit post
- Go offline
- Continue editing posts
- Go online
- Edit post
- Incorrect warning shows up
Do you mean the main reason, where software itself doesn’t recover cleanly, is unreliable internet/wifi/what-ever connections?