Looking at FileReader, I made a small edit, which can’t be seen.
At the bottom of the document, Last updated by is not my name – which is at the top of the history. And the revision itself does write that it’s not the current revision.
I’ve been editing heavily to remove old browser compat data for a few days, am I blocked by some automated defense from these activities, or maybe manually by someone with privilege?
Hi @urty5656! Thanks for reporting this. I do see your revision in the history of the page, and your name in the list of contributors. But I don’t see your changes when I look at what’s presented as the current version of that page.
We’ve had sporadic (that is, hard to track down) problems in the past with the most recent revision of a page not being displayed. But in those cases, I think the revisions were shown out of order in the history.
I could make some wild speculations about CDN’s and caching, but instead I will ping @ryanjohnson to make informed statements.
Thanks for your contributions! You’re not being manually blocked, and you would have to be inhumanly fast to run into any automatic rate-limiting.
I’m getting this today, too: https://developer.mozilla.org/en-US/docs/Web/API/RTCDTMFSender/tonechange_event 
I’m getting, too. My latest edit doesn’t appear. “Is current revision?” field of the revision doesn’t become “yes”.
https://developer.mozilla.org/en-US/docs/Web/API/AudioScheduledSourceNode$history
Thank you, @jswisher!
I’m manually “reverting” to the topmost revisions (i.e. mine) and it seems fine, at least for now.
Edit: No, it’s not okay. Um… My new revisions are still experiencing the issue. Reverting immediately is a solution, but I can’t do it all the time 
Sorry all, I’m looking into this now!
This should be fixed now, but please let me know if you’re still seeing problems. The PR https://github.com/mozilla/kuma/pull/5348 was the culprit (although I still don’t know the detailed failure mechanism as I couldn’t reproduce it locally or on stage). I deployed https://github.com/mozilla/kuma/pull/5366 to fix the issue.
Again, I’m sorry for the inconvenience this has caused. Thanks for your patience.
Florian just pointed me to this thread after I had the same problem lately (again) in bug 1288148.
@ryanjohnson Your patch may fix this issue for future changes, though it obviously didn’t fix it for existing ones. See e.g. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/type. So, is it possible to somehow correct those pages automatically? Because I assume my changes are not the only ones that are affected by this.
Sebastian
I just did a revert to the latest revision, with “https://discourse.mozilla.org/t/38443” as the revert reason.
Of course I can do that, too. Though as I said, not only my changes might be affected but also the ones from other people. Those changes will be lost, because no one checks the history first before editing a page. And I remember darkly that @teoli once fixed this bug for one site by somehow refreshing the page. (Hope my memory is correct on this.)
So again, if possible, I’d prefer an automatic and clean solution. If that’s not possible for some reason, just let me know and I’ll use the workaround at least for the pages I edited.
Sebastian