It could be that this only happens if one attempts to edit the last current section of a talk/meta page. I can't actually recall this happening in other cases.

I second this bug report. This bug happens to me quite often when I reply to an existing section (&section=x) on talk pages and some other editor added a new section in the meantime (&section=new). Both sections are on the same heading level, but obviously different.

If I understand T3553#58698 ff correctly, there was no objection in 2008 to removing the CSS text-transform feature from Monobook altogether. I think it should have been removed then, as such things tend to cause trouble much later. There is simply no reason I can think of that this should be the default, instead of a user setting in their own CSS.

As of now, it seems to have ceased. I'll keep checking.

I will now proceed to force-disable the extension by blocking api.php calls and see if this breaks something else.

@Aklapper: Steps to reproduce the problem:

I apologize for this side comment. It's an inside joke where I live and means as much as snafu.

The direct precursor to this bug seems to be T226503. "Everything fixed, no problem at all."

@Trizek-WMF: It would help if you stated what exactly are you interested in: The problem resolution from a technical perspective or the end user experience. The end user experience is well summed up in Gestumblindi's above comment of Tue, Jun 18, 23:05 (the ''acoustic coupler'' metaphor). At least that is how I experienced it.

It would be (mildly) tragic if that NGO (read multi-million dollar Corporation) was so far removed from its original purpose as to foolishly blunder over some stupid badge icons.

It is just that it's a little confusing - a company shipping a piece of software yet not taking any responsbility for it. I would prefer it if there was a clear communication or a timetable for a phaseout so that end users would know when, how and where their own initiative was required. Leaving things to rot is not my idea of what I expect from a service provider.

This issue is already discussed in the comments to T226594.

@Aklapper: Xaosflux has summed it up before me. I was just curious what would be the difference between "no full support" and "no support". Carrying wikipolitics on the backs of Wiki users (and volunteer developers) will not cut it, at least for me.

cp1077 is also producing this right now.

This goes to show the importance of testing. The uninformed user can easily construe such hiccups as being intentional trolling on behalf of WMF employees.

Shall we set this to resolved then? The active discussion on how to prevent this in the future seems to be taking place under another ticket.

This correlates to the previous appearance of the problem in early June, see https://grafana.wikimedia.org/d/000000352/varnish-failed-fetches?orgId=1&from=1559692800000&to=1559952000000.

It would appear that the problem sits somewhere in the Amsterdam cluster. Maybe we should focus on pinpointing which of the various hosts involved could be the cause of the issue.

My traceroute didn't reach any Wikimedia servers at all. A ping gives:

@Aklapper, I have used the network tab and from there I get the figure of >150 seconds. The status code is a 200, but the page loads in tiny amounts of data at a time, before a timeout sets in.

It's no longer an issue, at least on dewiki. Let's hope it stays that way.

You can test this by adding a page to a category and then immediately opening the recent changes page. The edit on the page is there, but the categorization isn't.

No cigar, yet. This had apparently been fixed in December, but is now broken again. Confirmed on dewiki.

Page categorisation seems to show on RC and watchlist again, although the Mediawiki version has not changed. A configuration issue, perhaps?

The bug T212078 (which has been marked as duplicate) is definitely not solved in 1.33.0-wmf.9, which is the currently running version on dewiki per https://de.wikipedia.org/wiki/Spezial:Version. Therefore I reopened this task.

Thank you. I am still convinced that this issue could have been solved differently than by rendering the whole section title as blue link, which breaks functionality.

Where exactly was this proposed in the https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017? Can't find it. Alternatively, any other community-based consensus/decision for this change,

On my local MediaWiki installation I solved this (for tables) by adding the following to MediaWiki:Common.css:

Well, in that case I must ask why this simple, yet really annoying bug has not been addressed for 5 years. Maybe because it is ranked lowest priority and has no assignee? I'm not asking for it to be done by tomorrow, but there have been numerous requests on-wiki for it to be fixed asap.

Shouldn't we rather assume that JS is enabled by default and use the <noscript> tag? Otherwise, the content would still collapse after a page load, which is what we are trying to prevent. There could be a be style element inside the noscript, for example, where the default (script) CSS behaviour could be overridden. Or am I on a wrong path here?