864347 - Kuma improperly caching content for editing?

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Editing, defect)

Description

[dan]

What did you do?
================
1. On April 20, 2013, using Firefox 20.0 on Fedora 19, I edited https://developer.mozilla.org/en-US/docs/Standards-Compliant_Authoring_Tools to update and remove some links; then saved the page.
2. I hit "Edit" again on the page to make some further changes (deleting the Bradsoft TopStyle entry from the bulleted list). I then hit "Save".

What happened?
==============
When I tried hitting "Save" for the second edit, I was served up a conflict warning stating that my change conflicted with a change that had happened back on March 22, 2013. As I was unable to determine what the conflict was (if any), I was unable to save the page.

A few days later when I returned to attempt to make the same change, I was able to save the edited page (having removed the "Bradsoft TopStyle" entry), but the content that was displayed after hitting Save still showed the "BradSoft TopStyle" entry. When I hit "Edit", the content to edit also, confusingly, showed the "BradSoft TopStyle" entry.

By hitting CTRL-F5 to do a hard refresh, I was able to see the correct version of the page. I had to do this hard refresh in both the normal view mode and the edit mode.

What should have happened?
==========================
1) I should not have run into a conflict with an edit that occurred a month ago.

2) When I hit "Save", any cached content for that page should have been flushed from Firefox's cache and/or local storage (not sure if Kuma uses that) and I should have seen my edits immediately in both view mode and edit mode.

Is there anything else we should know?
======================================

Comment 2

[ali spivak]

needs to be tested

Comment 3

[ali spivak]

I beleive this was fixed

Comment 4

[Matthew N. [:MattN]]

This definitely isn't fixed. I encounter this every time I edit a page that I edited shortly before and it causes me to edit MDN less since it's very frustrating.

Comment 5

[raymond [:retornam] (inactive)]

I tested this also and this bug is still valid. I have heard this from multiple people in the office.

Comment 6

[Luke Crouch [:groovecoder]]

We need some reliable steps to reproduce this because we never see this on development environments. :( :retornam - who in WebQA could help us get STR?

Comment 7

[raymond [:retornam] (inactive)]

STR:

1) Login to developer.mozilla.org
2) Pick any page to edit, make and edit and save the page.
3) Go back to the same page to make another edit, and hit the save button.
4) You are served a conflict warning page the after you hit the save button even though there is no conflict.


I've seen Mattn reproduce this several times.

Comment 8

[Luke Crouch [:groovecoder]]

I can't reproduce this reliably. I have no problems editing https://developer.mozilla.org/en-US/docs/User:groovecoder over and over again. I get no conflicts.

Are there specific pages that cause the most problems?

Comment 9

[Matthew N. [:MattN]]

My apologies. This seems to be caused by NoScript which was quite surprising to me and I assumed this bug was still the issue. I've reported this to the extension author now.