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)
Tracking
(Not tracked)
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.
Comment 1•10 years ago
|
||
> ====================================== > 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
Comment 2•10 years ago
|
||
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
Updated•10 years ago
|
Assignee: nobody → lcrouch
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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 5•10 years ago
|
||
Comment 4 is consistent with my own experience. The workaround for now is to force refresh in the edit interface.
Comment 6•10 years ago
|
||
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?
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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?
Comment 9•10 years ago
|
||
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...> <p>Bat!</p></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
Comment 10•10 years ago
|
||
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?
Comment 11•10 years ago
|
||
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
Comment 12•10 years ago
|
||
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.
Reporter | ||
Comment 13•10 years ago
|
||
(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.
Comment 14•10 years ago
|
||
I attempted to test this and got the revision collision upon the second edit attempt. :/
Comment 15•10 years ago
|
||
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
Comment 16•9 years ago
|
||
Is this still relevant?
Updated•8 years ago
|
Assignee: lcrouch → nobody
Comment 17•8 years ago
|
||
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
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•