I am a member of a Discourse forum (BlenderArtists.org) and I have a 4K monitor which allows me to have two pages of the forum placed side-by-side.
Sometimes, when I plan to write a long comment, when I prepare my answer (with several quotes from current long thread), I open the Message Editor on the left page and I browse the same thread on the right page.
But when I do that, this message appears very often:
Draft is being edited in another window. Please reload this page.
I am not against this warning (I am sure it is useful in some circumstances).
But would it be possible to add an option in the user preferences to disable it? Or to set the frequency of display (the timer)?
This warning message prevents to write the message peacefully.
We automatically (try to) open the draft for editing when you enter a topic. Even if you immediately minimize the composer, it’s still live and conflicting.
I’ve been bitten by the draft auto-opening as well, but it’s worse than just getting the warning message. I’ve gone back to typing my post and then gotten the popup later, trying to direct me back to the other tab that has an older draft. At that point if I refresh the page I only get the older version of my draft, so in that sense this feature isn’t really preventing what it’s trying to prevent.
I’m not sure if it happens before you start typing. I just tried reproducing on meta, and it only happened when I started typing in the second tab. I tend to trigger this shortly after duplicating my tab to cross-reference what I’m writing. I lose track of which tab I started in, and when I start typing in the second tab by mistake the warning appears.
Would it be possible/reasonable to detect if another tab already has the composer open for the given topic and if so not open the composer for the new tab?
Too complicated really… there may be something we can do with web workers, but it is an enormous change I would not like to do.
I need an exact step by step repro, our warning kicks in really early, at worst you would lose a few words. I guess if you are offline then stuff can get weird, but that is a big edge case … work around is cut-and-paste.
I just had a look at the OP.
I can not repro this, can you provide exact steps that lead to this incorrect message. If you are not editing there is only 1 edge case where you get this message arguably incorrectly. But it is a very minor edge case.
Open tab 1 … start composing reply
Open tab 2 … browse around
On tab 1 … continue composing
On tab 2 … minimize composer (you get a warning message… but only once)
What can happen which may be tripping you:
Open tab 1 … start composing reply
Open tab 2 … by mistake quote something for reply
On tab 1 … continue composing … warning is there … persistently (cause we would be throwing away the quote from (2))
I am just not sure what to fix here… I need repros.
I’ve definitely had times where I lost a significant amount of content. For that reason though, I’ve been careful not to trigger this warning, so I don’t remember the exact steps that caused the significant loss at this point.
I think the problem might be if this saves a draft, overwriting what you did in tab 1. If that happens, that could result in significant loss of content. That’s just speculation for now, but I’ll see if I can reproduce the issue that way and let you know.
I understand that you need repro steps. I set a reminder () to look tomorrow night. It would help to know (at a high level) how the conflict test works. Is there a unique identifier generated on page load or something like that?
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.
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.
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.
) to look tomorrow night. It would help to know (at a high level) how the conflict test works. Is there a unique identifier generated on page load or something like that?
