10

Just now I was editing a question, fixing tags and body. Before I submitted my (2k) edit, someone else edited, changing some of the same tags as I. Well enough; my edit was more complete, so I'll just submit anyway, right?

Wrong!

I get a bizarre popup from the tags field saying something about a previous editor had changed the tags and therefore I would need to refresh the page and try again.

Which I did (before getting a screenshot, unfortunately), and, of course, on reload the draft was completely erased, forcing me to resort to Lazarus Form Recovery to avoid retyping from scratch.

This is not good UX and should not be happening. A tag-only edit is not magic*: if conflicting, the new edit can be layered on top just like any other conflicting edit.

A further, even more irritating glitch is that the editor dialog will also incorrectly display error messages for the other fields if they are edited. For example, if I edit the title — even if the other editor did not — it will display an error that the title was already edited.

*Unless it is. But why?

3
  • 2
    ctrl-a ctrl-x, refresh, ctrl-a ctrl-v is what I do...
    – user1228
    Commented May 13, 2015 at 19:08
  • @Won't: I have an addon (Lazarus) that does a better job at that part. That's not the main problem here. The problem is the tag-only edit somehow interfering with the usual submission override that normally allows the second edit to go through anyway. Commented May 13, 2015 at 19:13
  • 1
    We’ve reviewed this request are moving it to our backlog. I’ve updated the status to status-deferred.
    – Slate StaffMod
    Commented Feb 9, 2023 at 22:04

2 Answers 2

7

This is something I'm currently looking into fixing. The best way to handle this would be to allow you to load a diff of the edit that was just saved against what you currently have, then let you decide how to proceed.

In implementation, it's a tad more complicated, but we do want to fix it. It's particularly annoying in review, where most work on substantive edits.

Hope to get on it at the end of this month.

8
  • So, [status-planned], then? Commented May 13, 2015 at 4:07
  • @NathanTuggy Maybe at the end of the month or just 6-8 weeks ;)
    – rude
    Commented May 13, 2015 at 5:06
  • 1
    For context I was concerned about this when we rolled out the Help & Improvement queue. We mostly skirt around the issue there with short-lived locks, but that was with the idea that we'd eventually just make the process better.
    – user50049
    Commented May 13, 2015 at 6:19
  • 1
    End of May was... a while ago. Commented Dec 18, 2015 at 11:41
  • @Nathan status-planned means, as far as I came to learn, that a developer is actively working on a fix. Though, would love to stand corrected by Tim. :) Commented Dec 18, 2015 at 11:45
  • Still working on the fix? Commented Dec 25, 2015 at 20:06
  • 1
    @Jan judging by the lack of any response, I would say a plain "no". We can try again in 6-8 years. Commented Mar 12, 2016 at 6:34
  • @ShadowWizardChasingStars How prescient! Almost seven years is a pretty close match, wouldn't you say? Commented Feb 10, 2023 at 20:56
1

Here's a workaround: open the post in a new tab, make any edit you care to, then re-submit the original edit. Since you were now the last editor, it will go through, and will effectively replace the temporary edit in revision history.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .