In T22288#8502696, @Umherirrender wrote:

When a suppression missed a log, there is no way to create a log entry afterwards. It could be a small time of a software error which results in this situation or the log exists under another page name.
For very old suppressions it is possible that the suppression was done with the old oversight extension and that was using other logs.

In T112147#7736665, @Quiddity wrote:

In T112147#7728596, @Urbanecm wrote:

@Quiddity I'm not sure if this warrants a "it is completed" notice in the tech news. Moving the task to To Triage for you to look at -- I'll appreciate your opinion here.

I don't think this needs to be re-announced as completed, as it was included 4 weeks ago, and (IIUC) there are no required actions from communities/individuals (unless they want to override the default/default-translation from translatewiki).
If I'm missing an aspect/nuance, that would mean it is crucially important for everyone to be aware of, please let me know.

Hmm, yes, it does appear to be added now! I'm not sure when, but it appears to be only for new entries. In theory, I suppose, that means when it happened should be fairly findable. ETA: I went ahead and did it, looks like it was something in 1.37/wmf.4.

I think OSers should see the bold — we want the visual differentiation — but it does show for non-OSErs. Is that a problem? It reveals more information that way. It's occasionally possible to determine via absence in public logs, but not always. Diffs aren't readily accessible, but they do appear to show the same thing and explicitly state revdel or OSed.

@Urbanecm I imagine most folks making the mistake expect "xxdir" to be a "sorted by," so likely misread "in which direction to enumerate" as "sort by" when it actually means "items move in this direction." Similar to if you're driving south, you'll pass the most-northern exit first.

@Aklapper Is it possible you misread this? I don't really know what the editor has to do with it (it's already there) or what this has to do with the latest revision specifically?

You can use the name of the checkbox, so document.getElementsByName('mwProtect-cascade')[0]

No idea!

@Milimetric Ach yeah, it'll be some ad blocker. Haven't figured out which yet, but sorry for hassle. I've also just found T86680, which makes it clear.

@Ottomata Firefox 78, but I also get it in Safari; a quick test suggested I wasn't seeing it in Chrome?

@Aklapper it's navigator.sendBeacon(config.serviceUri, JSON.stringify(eventData)); in the core.submit definition, which, from codesearch, is from the Event Logging extension: https://gerrit.wikimedia.org/g/mediawiki/extensions/EventLogging/+/a27b4a1f3d235ace86d93c4f2bb4a60fcb7c9b97/modules/ext.eventLogging/core.js#398

Just by means of an enwiki update, I wanted to note this discussion on the int-admin's board: https://en.wikipedia.org/wiki/Wikipedia:Interface_administrators%27_noticeboard#Removing_legacy_javascript_globals_from_skin_pages

There's a discrete (if lengthy) number of items, so one could list 'em all. Alternatively, regex makes it fairly doable (this is what I was doing).

FWIW on enwiki (which I presume is the bulk of it), I intend on reviving that this weekend since I do have a list to go off of.

I'm discussing this with legoktm on-wiki, but I want to apologize here to all I put in a tough position on a Friday, especially you Andre as it seems I did not appreciate the severity or urgency of your note in T272526#6769471.

Wasn't trying to blame you or anyone @Urbanecm, sorry if it came off that way; I just meant that we were asked to deal with this locally since there wasn't movement here and folks were antsy. Not the first time that enwiki had a different timeline in line than the dev volunteers!

Yes, thanks @Aklapper, I was indeed aware of that. No one intends this to be the solution, just a stopgap since work here stalled and nobody can continue until the beginning of next week, nearly half-way through the allotted timeframe.

Per community consensus, I've put up the hacky CSS to put in a new image. This is not ideal, but given the time frame, folks wanted it. Please do revert if it slows everything way tf down

I may be mistaken, but isn't the issue with the eventual removal (not the deprecation here) that there are, as noted in T270796#6714564, a huge number of uses of these in active use? If there are really hundreds of thousands of edits to be made, I'm not sure saying "the old class names... don't work..." is entirely accurate.

Already in use, thanks all!

Yes, just like block/T257662

In T271804#6739764, @daniel wrote:

Triggered by requesting page info of non-existing pages. Should be fixed by the patch I just uploaded.

Just to confirm @MusikAnimal, am I right that this change has also tweaked (corrected?) the return value of watched when using format=json&formatversion=2? Without this change, a title I'm not watching returns "watched": false while after this change, it does not return watched. That's seems more correct, but just wanted to confirm since it wasn't mentioned.

This is likely to become more apparent once T206954 is fully implemented.

I suppose that's a better/bigger point than just the api: the on-wiki block log differs (1, 2) despite blocking being the same.

I think -Blocks, but yeah, thanks

I suppose it depends on how you view wgRelevantUserName. It doesn't exist for non-existent usernames, which maybe implies it shouldn't be defined outside CIDR limits? Regardless, that fact makes wgRelevantUserName a reliable "does this single editor exist?" marker. IPs and specifically IP ranges are clearly a different beast, but at the moment, wgRelevantUserName indicates a working single user (ip or registered username), and is unhelpful for ranges. After this, it will indicate a registered user, a single ip, or a range; if it doesn't take into account CIDR limits, then maybe it's sort of a "anything I see would have a talk page" marker, but it would no longer be a reliable marker for "can I do things (e.g. block) with this?" On the flip side, something like mw.util.isIPv4Address doesn't bother with CIDR limits, so one might not expect this to, either.

Will this/these define wgRelevantUsername for a range outside of the CIDR limit? Similar to your proposed work in T211910 @Ammarpad, but curious to know.

That, and: since I can toggle my watchlist freely on the page, I think that would make it the *only* mw.config item to be able to change once the page has loaded? That would be weird.

To clarify (@DannyS712 you might be able to correct me if I'm wrong) without this, I don't think there's a reliable way to get watchlist expiry status for a given page? T263796 helps but wouldn't cover it.

@Umherirrender Indeed — that'd be T27912, which, no joke, you opened exactly ten years ago!

@DannyS712 Sorry, I realize in my haste I wasn't fully clear: I meant a page protected only by virtue of being transcluded, not the page that is directly cascade protected. See, e.g., https://test.wikipedia.org/w/api.php?action=query&format=json&prop=info&titles=Page4242&intestactions=edit%7Cmove

Duplicate of T265763, I believe

@Demian I filed that as T265832, I think it's related to T248751 not this, based on when it started to appear.

Superficially, this looks related to T256466? AFAICT that looks to have been resolved sometime in the last week or so, so I can't confirm the message I received there, but the (fractional?) request url here would suggest a different pathway.

@Fomafix Can you still see this? I'm no longer able to replicate it, so I'm hoping this got fixed somewhere.

It is: the AbuseLog entry won't be crossed out and italicized, but it should have a trailing (hidden because revision has been deleted), which is accurate. It will still show up as "visible" in the search filter since it was not explicitly hidden, but it remains tied to the revision. That is, if the revision is unhidden, the AbuseLog entry will be as wel.

In T202989#6557660, @Thryduulf wrote:

There is no justification for preventing administrators viewing or restoring this.

Thanks for the bump @Umherirrender, I've been meaning to comment that yes, I haven't run into it at all and even after removing my safeguards, don't trigger it anymore so seems great on my end AFAICT.

Love it.

FWIW, it looks apihelp-stabilize-param-watchlist needs adding to all the i18n pages. Presumably it can just copy the text used everywhere by apihelp-*-param-watchlist in core?

The difference, though, is that history-deleted is marking text that is used as a stand-in for the hidden user name in a history or diff, whereas this text is presented in addition in order to provide some information, as the username is not displayed on each li on Special:Contributions. This text is thus (potentially) the only marker on Special:Contributions that a revision has had just the username revdel'd. Removing it would be harmful: the main reason I opened this was so that scripts could detect hidden usernames on a contribs page, but even in normal usage, it's the best way to confirm that a user's revisions have been sufficiently hidden.

In T255903#6473414, @Ammarpad wrote:

...history-deleted will gray and cross-out the message, which is not what would be wanted here.

Please explain why. I'd rather have the behavior be consistent (for things that are basically the same) than introduce new arbitrary class.

That's a good bet, AFAICT, but hundreds of times?! It's clicking the button that adds the term and reloads, so getting to hundreds or even dozens seems unlikely from manual use. There are currently only seven users importing it so if so it should be easy to nail down, especially given the tight timeframe today.

I think script authors should do some existence check instead of blindly assuming relevant user is set always.