It was a bug in the CSS after all, due to the inspection. It felt like, as a website enthusiast, that the CSS that references the text in the positive rep which is green is overriding the text inside the special case for bounties which is white to avoid what happened today.
After I inspected, turns out it is the case, and the problem is now figured out. The ...
This should be resolved. We have increased the error logging in the tag engine to capture if this happens again, but as a part of the move to .NET Core all of the tag engine is being replaced and is actually in the process of rolling out.
We'll be monitoring the rollout of the new code and hopefully will spot this if it happens again.
It shouldn't be omitted in this particular case, since it's still possible to vote on the answers - you can try it out yourself. There are so-called historical locks which completely lock down voting on all posts, for which not showing the banner would make sense. (Maybe it already happens there?)
I do agree that it would be nice to change it to something ...
Update (2019-7-15): A new tag engine build has been deployed and .NET Core is back in rotation.
The tag engine port had one critical bug in it: for Teams (or Channels - that's our infrastructure name), we filter which sites we're going to reload. It's simply not practical to load the delta for thousands of "sites" if they haven't changed. As an optimization ...
I can confirm the behavior claimed in the OP happening.
Right ATM when I viewed the above question (again), and clicked at the Questions link, it wasn't listed at the homepage of Meta Stack Exchange.
I also noticed that this recently happens with other sites at the SE network.
I believe there must have been some recent change regarding the visibility of ...
I just fixed this.
I'd accidentally left emboldened font in a rule for all of these elements in our less file instead of just for the ones with the unread-item label. It was something I'd put in during testing to figure out where the put the rule on the unread-items label but I forgot to take it out after.
Sorry! Thank you all for finding it quickly so I ...
Okay, I have found a solution: when I create a new, unrelated filter, then the old, hidden filter suddenly appears. Then it is possible to delete or modify it. So the solution is to create a new filter.
Detects when you visit a SEDE page (targe page) but aren't logged in.
Automatically logs you in. (Currently only supports Stack Exchange's authorization/OpenID.)
Once SEDE is logged in, the script then redirects back to the target page from step 1.
Here's an install-from-GitHub link. (Requires the Tampermonkey or the Violentmonkey browser ...
Ok, this is fixed - all comment flags will be henceforth ignored for the purpose of this check, along with any "in need of moderator intervention" flags raised on the post itself (that exception already existed).
Thanks for pointing this out; by my estimation this was probably responsible for around 700 invalidated reopen reviews on Stack Overflow alone, ...
Adding details in hopes of getting developer attention.
Reproducing the issue from a clean state.
I believe this may be how to reproduce this issue. I can't verify, because I'm already in the broken state.
Start with at least 1 existing, valid filter (with tags and everything).
Click New Filter.
Instead of finishing that filter, click on the existing, ...
I have the same issue, Try to switch to traditional editor. It worked for me.
How to switch to traditional editor:
Ignore, tag and title sections, when you are asked to input your question, there is a little button at right upper corner, click on it.
The reversal you mention happened at 03:00 UTC that day, and reversed the serial votes from the previous day. Then, the three serial votes you highlighted happened later, at 09:17-09:18 UTC that day.
The serial voting script runs once a day at 03:00 UTC. Since the serial votes you mention happened after that time that day, they'll be detected by the next ...
Both are considered "recommend closure" flags. The duplicate reason is also one of the close reasons with which a post can be closed, and once you retract a close flag for any reason, you can't flag it again, for any reason.
The fact that there's a separate option to link straight to the duplicate reason can make this a little confusing, but as your link ...
Code fences weren't supported until January 2019, so any post that used them before then had them rendered as simply inline code. You do need to edit and save in order for the post to be rendered using the new Markdown processor.
We added a few new activity types to the database for other purposes today, and neglected to revise the query and code that handles the activity list. We probably don't want to pull down every upvote and downvote here (it's your public list of activities...) and the code certainly wasn't expecting them to come back from the DB... But we were, and so the code ...