Closed Bug 1063582 Opened 10 years ago Closed 8 years ago

Edits on MDN are not seen until a refresh

Categories

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

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sheppy, Unassigned)

References

Details

(Whiteboard: [specification][type:bug]) 

What did you do?
================
1. Opened a wiki page on MDN. Any page will do.
2. Clicked Edit.
3. Added "This is a test" to the page.
4. Clicked "Save changes".
5. The page does not reflect my change.
6. Clicked refresh. Does NOT have to be shift-refresh.
7. Change is visible.

What happened?
==============
See above.

What should have happened?
==========================
You should not have to reload to see your change.

Is there anything else we should know?
======================================
We've had this happen in the past, but now it's happening every single time, both on prod and stage.
> ======================================
> We've had this happen in the past, but now it's happening every single time,
> both on prod and stage.

This is more complex than comment 0 implies. For example, I can replicate every time in Firefox, but not in Safari. When I replicate in Firefox, I also get the midair collision described in bug 1047116 (which requires a force refresh in the edit interface to resolve). In other words, something about the way the browser is caching content is involved here.
Severity: normal → major
See Also: → 1047116
Escalating this to blocker. I've hit the same problem as described in comment 1, but now every time I hit "edit", I get the old version in the editor, even though I see the new version on the page. I tried discarding changes and refreshing in "edit" mode, no luck. This has the potential to make MDN entirely unusable or overwrite older changes, so I suggest a higher priority here before more people run into this.
Severity: major → blocker
Assignee: nobody → lcrouch
Which page? On https://developer.mozilla.org/en-US/docs/User:codegroover, I get the stale content after a save, but I do *not* get stale content in the editor.
Flags: needinfo?(choller)
I was editing https://developer.mozilla.org/en/Building_Firefox_with_Address_Sanitizer and solved the issue by shift-refreshing the editor page. The exact steps I took were:

1. Edit the page, save.
2. After returning to the page, hit edit again (because the page didn't update), then I saw that the content is up-to-date. I hit save again.
3. After returning to the page again, I hit reload and saw the new content.
4. I hit edit again (because I needed to make new changes) but then I had the *old* content in the editor.


I don't know how that could possibly happen.
Flags: needinfo?(choller)
Comment 4 is consistent with my own experience. The workaround for now is to force refresh in the edit interface.
I saw Justin having this (the edition UI not up-to-date) problem during the last bug swat; and I did the same steps without seein it

It seems that some people have the second part of the problem (content of the edition UI not up-to-date) all the time, and others never (or almost never).

What could be different between the two groups of people? How could we assess how many people are affected by the more severe form of the problem?
Can someone who's experiencing this do a "View Source" and make sure that, when the editor shows wrong content, that the server is sending out the wrong content, and not something freaky going on on the client side?

Two "freaky" things I that, in theory, could happen is (1) CKEditor someone caching and showing the old stuff and (2) a draft someone being auto-applied.  I doubt it though.

I just want to make sure it's a server-side issue.
I'm currently chasing down this as a possible cause:

https://github.com/mozilla/kuma/blob/master/kuma/wiki/views.py#L430

I.e., if the last-modified cache key isn't updating after a save, the view will bypass the DB completely.

To help verify, can a few folks also check the HTTP status codes that are returned when you see stale content? Are they 200's or 304's?
The HTML contains the same content as the CKEditor. I just edited my own page[0] to contain this line:

Bat! Bat! Bat! 3 times.

Before I made that change, my page contained this line:

Bat!

When I edit the page[1] after making my change, I see this:

Bat!

When I look at the source, I see this:

<snip...>
&lt;p&gt;Bat!&lt;/p&gt;</textarea></div>

In the console I see a handful of 304s, and all the rest are 200s. The 304s are:

https://developer.cdn.mozilla.net/media/js/wiki-min.js?build=f637cb9
https://developer.cdn.mozilla.net/media/css/mdn-min.css?build=f637cb9
https://developer.cdn.mozilla.net/media/css/wiki-min.css?build=f637cb9
https://mozorg.cdn.mozilla.net/media/css/tabzilla-min.css
https://mozorg.cdn.mozilla.net/en-US/tabzilla/tabzilla.js

If I force refresh the editing interface, the problem is resolved. The newest content displays in CKEditor, the HTML is still aligned with the content in CKEditor. All of the network requests are 200s.


[0] https://developer.mozilla.org/en-US/docs/User:hoosteeno
[1] https://developer.mozilla.org/en-US/docs/User:hoosteeno$edit
After a bunch of testing, I think this is a Firefox bug ... and I hope that's not a cop-out. Here's what I found ...

Works fine in Chrome

In Firefox ...

1. POST to $edit returns 302 with Location url
2. Firefox does **NOT** GET the Location url
3. Firefox : Settings : Advanced : Network : Cached Web Content : "Clear Now"
4. POST to $edit returns 302 with Location url
5. Firefox **DOES** GET the Location url with a 200 status response and updated content

So, someone else try clearing your Firefox cache to see if it works?
My last comment was a post-it-before-leaving-for-the-weekend Friday afternoon comment. Anyone else able to check this? 

I used Tamper Data [1] to record the HTTP requests between Firefox and MDN.

For some reason, Firefox seems to aggressively re-use cached responses for 302s from MDN. I.e., when you click save on <doc>$edit [2], you get back a 302 to <doc> [3]. But Firefox doesn't wait for a new request to <doc> - it simply serves the cached response from before you went to $edit. It effectively makes the "save" button work like a "back" button. :/

I'll dig into it some more today, but would like to know if it's just my Firefox that's mis-behaving, or if others are seeing the same issue.


[1] https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
[2] https://developer.mozilla.org/en-US/docs/User:hoosteeno$edit
[3] https://developer.mozilla.org/en-US/docs/User:hoosteeno
Shouldn't we send "Cache-control:no-cache" with $edit pages like https://developer.mozilla.org/en-US/Firefox/Releases/24$edit ?

Not doing it allows Firefox to cache the $edit page, not seeing it becoming a 302 when we click save.

Not 100% sure of my analysis, though.
(In reply to Jean-Yves Perrier [:teoli] from comment #12)
> Shouldn't we send "Cache-control:no-cache" with $edit pages like
> https://developer.mozilla.org/en-US/Firefox/Releases/24$edit ?
> 
> Not doing it allows Firefox to cache the $edit page, not seeing it becoming
> a 302 when we click save.
> 
> Not 100% sure of my analysis, though.

That sounds sounds logical to me.
I attempted to test this and got the revision collision upon the second edit attempt.  :/
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/9822200f53198f9faaabc4b204028a49b10cae97
bug 1063582 - never_cache edit_document or translate views

https://github.com/mozilla/kuma/commit/6a4793a27d11cd8ffaa86ec9adb5815d76615c44
bug 1063582 - add test for never_cache decorator

https://github.com/mozilla/kuma/commit/db5035d672d6d994d519b9d09ec10488bcc274f4
Merge pull request #2745 from groovecoder/edits-unseen-1063582

bug 1063582 - never_cache edit_document or translate views
Is this still relevant?
Assignee: lcrouch → nobody
Marking importance down to "major" and resolving this as fixed. This is an old bug, and I think my update on the assignee field re-triggered the nagios alerts for critical/blocker bugs in the MDN product.
Severity: blocker → major
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.