Edits that shadow a suggested edit inconsistently reject but include the suggestion

Question

I have the edit privilege. If I edit a post which has a pending suggested edit, then:

• My edit starts from the version resulting from the suggested edit. I'm not notified of that, or even of the existence of the suggested edit.
  (There's actually a clue, but it's easy to overlook — the edit summary field is pre-filled with the summary from the suggested edit.)
• The suggested edit is marked as rejected by Community with the message “This edit conflicted with a subsequent edit.”
• The suggester is not credited in the edit history, my revision combines the suggested edit with my modifications.

This can happen if an edit is suggested while I have the page open: I click on “edit”, and think I'm editing the version that I was just reading, but in fact I'm editing somebody's suggested edits. It also happens if I deliberately visit /posts/12345/edit, which used to provide a valid way to improve an edit after having clicked on “Approve” but while it was still waiting for others to review.

Examples: a suggested edit that I approved and then wanted to improve; a suggested edit where I clicked “edit”.

There are two bugs here, but I'm making a single report because they're very closely linked.

• I'm not told about the suggestion, so my edit includes content that I'm not aware of, yet is attributed to me.
• The suggestion is marked as rejected and the suggester is not credited in the edit history, yet the suggested changes are made.

Answer 1

The issue present here occurs when:

1. You (a user with full edit priviliges) are looking at a question page.
2. User B submits a suggested edit to a post on that page.
3. You click "Edit" and get either the full editor or inline editor.
4. You make changes and submit the edit.

This results in what you noted in your question:

• The editor is pre-populated with the contents of the suggested edit (but no indication of this, other than the edit summary being pre-filled).
• The suggested edit is going to be rejected due to conflict.
• No credit will be given to User B.

A fix for this is now in place:

• When you click "edit" on the question, a server-side check is now made to see if a suggested edit is in place. (Previously, the check was client-side only, and only occurred if the post was loaded after the edit was already suggested.)
• If there is a pending suggested edit for review, you will either load the inline suggested review modal (in the case of an inline edit) or you will be redirected to the Suggested Edit Review page (in the case of a full /posts/POSTID/edit page load) with a toast notice informing you why you ended up where you did.

You can then choose actions based on what is available on the Suggested Edit Review page (and either add your edits through there, or make your edits after you are done on that page).

Credit for this fix goes to Shog9 - this is something that Shog worked on last January, and was accidentally overlooked and not reviewed, tested, and finalized until now.

---

View post, want a change
Suggested edit pending
Shog to the rescue

Answer 2

I just did some testing and I believe that this a historical artifact of how the "Improve" button used to work in the Suggested Edits review queue, before the review system was revamped in 2014.

Back then, the "Improve Edit" and "Reject and Edit" options would be combined into a single option, known as "Improve", and that option would always load in the new suggested edit for the reviewer to improve. They would then be shown a choice of whether the suggested edit was helpful or not, which would indicate whether the subsequent changes on top should be an improvement on top of the suggested edit, or if the edits should be applied but the author shouldn't receive credit or reputation.

I was able to piece this together from the following facts, using my browser's developer tools:

• I saw that the review type ID for the "Improve Edit" button is 5, the same as that of the "Improve" button from when the system was originally designed. (I can't say this for sure, but as Approve is 2 and Reject is 3, but Reject and Edit is 19, and the overall order of review type IDs seem to be in the order the buttons were first introduced, this seems to be the case.) This means that today's Improve Edit button is loading in the same form as the past Improve button.

• After looking through the series of AJAX requests made by the page when clicking the button, it seems to be loading in the exact same editor page that would be loaded when editing a post (/posts/[post ID]/edit) (but adds more review-related features which I'll get to in a moment). The system normally blocks external access to this form when there's a pending edit: users who load the page while there's a pending edit will be directed to review the edit when they click "edit". If the editor form is loaded anyway, it thus makes the assumption that it's being loaded in from the review queue's Improve [Edit] option and thus preloads in the suggested revision. (As you point out, that assumption is not always correct.)

• Looking through the DOM of the review page, it seems that the old "suggested edit was helpful" checkbox is still present in the DOM, and checked by default, but is now hidden with CSS. (Which furthers my first point, that it's still using the same form as the former "Improve" button.) As a test, I suggested an edit while logged out, then used Developer Tools to unhide the checkbox, and unchecked it. I got the same behavior as you: the edit was automatically rejected as an edit conflict, but the suggested edit was applied. (It also listed me as reviewing it as "Edit" - there's another thing added to record a review on saving the edit.) It seems that unchecking that box triggers the edit conflict logic - and this is what was used to physically reject the edit by Community in the past.

• As far as why unchecking the box triggers the "edit conflict" message: keep in mind that prior to August 2014, edit rejections by Community for any reason didn't have a message attached to them - they would just show as rejected by Community with no explanation. As the outward behavior in both cases (unchecking the "edit was helpful" box and actual edit conflicts) was the same, they implemented the uncheck logic by intentionally triggering an edit conflict. (This also explains why before the edit review system was revamped into the modern set of buttons, no edit rejected by Community would count toward editing bans - as it wasn't possible to differentiate between those two cases.)

tl;dr: the reason why this bug is happening is because of historical logic from the way the edit review queue used to operate, plus the not-always-true assumption that users can never access the editing form while there's a pending edit.