Thank you. I initially thought the error might have something to do with Temporary Account and I didn't want to break any plans related to it; This is why I thought I'd ask.
Now it seems like it doesn't, so I'll make a patch for this.

Just leaving a memo: User::isBlockedGlobally has been deprecated since T317337.

Closing this task as invalid because radical backporting is the only way to resolve it.

I assume you're from a non-WMF wiki but on WMF wikis at v1.43.0, the reported error doesn't occur, and both &oldid=prev&diff=xxxx and &diff=xxxx work for the first revision. I think you should talk to a sysadmin of the wiki farm about whether to update the MediaWiki software.

This doesn't sound like a bug to me. It's probably just a matter of caching, and I think it will resolve itself once you add codes for action=purge into pt:MediaWiki:Gadget-fastbuttons.js/core.js.

@Dreamy_Jazz Is it okay if I make a patch for this?

Unfortunately, there's no way to debug this unless we can reproduce the issue. @Mondo, you might want to let us know immediately when you come across the issue next time.

In T358416#10050846, @matmarex wrote:

@Dragoniez Class fields are actually an ES13 (ES2022) syntax feature (see https://en.wikipedia.org/wiki/ECMAScript_version_history#13th_Edition_–_ECMAScript_2022), which is not yet allowed by the validator (T357197), because MediaWiki still supports browsers that don't understand it (compare https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#browser_compatibility and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix).

I misrecognized these “class fields” as ES6 features, and they’re actually ES2022 features. My apologies.

My apologies, it appears like these “class fields” were added in ES2022. It’s natural that ResourceLoader isn’t compatible with them yet.

If we load a script with an ES6 class involving non-method properties like the following through ResourceLoader, it fails to be parsed.

class MyClass {
	bar = 'bar';
}
const cls = new MyClass();
console.log(cls.bar);

This sounds like T367982 but you posted a comment there before it was resolved, which makes this new task sound like something else was going on. I can't reproduce the issue even on Timeless, though.

This is caused by the hackish coding in alterForm added in c289d74550451290cb625c8b87b6ad622adaf371.

In T371179#10020827, @ShahZamanPathan wrote:

local discussion link here

@ShahZamanPathan Have you gathered local community consensus for this change?

I managed to identify the cause of the reported situation: pending changes.

This is bizarre. This one seems to be relevant only to the project, article, and user type, and also the skin doesn't seem to make a difference. I tried importing the article to testwiki but couldn't reproduce the same issue.

In T370669#10003733, @DannyS712 wrote:

Actually, caused by ad1e36d6f6d94827b4928094c708e8340d086e5b so thankfully its only been an issue for a few weeks rather than since 77781b08c7d9268b8ba6aea8ac8e667ba5666d57 4 years ago - just a missing !

Sorry, this might be a duplicate of T368203.

@Jack_who_built_the_house Thank you for the updates! I no longer see the issues in Op and they appear to have been fixed.

In T358076#9565154, @Umherirrender wrote:

Maybe a captcha was shown and abuse filter already logged the first try, but the account was not created (captcha not filled). But I have not tested that.

As abuse filter is working very early for the checks, it may have some logs even the action does not happen.

In T357757#9552941, @taavi wrote:

Which problem is this trying to solve?

In T355063#9460635, @Vikipolimer wrote:

Which log type do you want to control, e.g. only "protect" or all log entries?

All, I would say, if I’m asked to think about the fundamental spirit of this task. But I’m guessing a step-by-step implementation would make a good starting point if it’s going to be too time-consuming.

@Vikipolimer Thank you, and yes, something like that. If I were an anonymous user and the log #65 had been action-deleted, then the response array in the 2nd example should be empty because the object in it is the only log that matches the current protection settings of the page Hello.

Or, leave action-hidden logs in the response and only show what can be shown, e.g. logid and timestamp. This may be another workaround.

(Just adding a mention) T307827

The same kind of reports can be found on ja:WP:VILLAGE and ja:WP:HELPDESK as well.

And what I wrote above was inaccurate, the issue persists in the links below section headings as well when enclosing the comparison operator with nowiki.

In T336142#8833256, @Ladsgroup wrote:

It's not as simple as it looks, watchlist_expiry holds an extra column as the timestamp that's binary(14), in enough size can undo the benefits by being bigger than of holding them unconditionally in watchlist.

I see. Thank you all for your help.

In T336142#8833194, @kostajh wrote:

Ah, OK. Cc'ing DBA -- the code comments for the Watchlist expiry feature mention that 1 year exists as an upper limit due to concerns about database table size for watchlist_expiry.

Alright, that makes sense. Permanently having 10k+ pages in the watchlist or some of them getting removed periodically, I wonder which is parsimonious for the database. Thanks, Community-Tech.

I appreciate your help. I guess the dropdown options can be the same and don't have to have an option like " 3 years". For my purposes, the API is the only one that I want to be modified.

@kostajh That's an option but not the best one, as far as I'm concerned, because any time we protect a page for more than 1 year, it'll be necessary to watch the page indefinitely. This will take up too much "space" in the watchlist.
The thing is, older users have so many pages in the watchlist, and probably the situation is even worse for sysops who surveil pages that have previously been targeted for vandalism. The more pages the watchlist has, the slower it is loaded.

Weird. When I tried to identify the cause of the issue illustrated by the first picture in Op, I didn't see any error message in console but now I get one for the deprecated p-namespaces, and also it's now impossible to reproduce the misaligned portlet link as in the image and in fact no portlet link is added to the position if I use p-namespaces (although this behaviour is normal because it just means p-namespaces is missing. Maybe there was p-namespaces when I initially filed this task but now there isn't? I don't know.) This task can be closed now, it would be a waste of time to try to "fix a bug" for the deprecated feature. I appreciate your help.

@Jdlrobson
That script isn't quite a gadget actually. It's just an experimental script made only for demo purposes for a discussion in village pump.
The following code replicates the misalignment issue, so I believe this is an issue of the vector-2022 skin.

mw.loader.using('mediawiki.util', function() {
    mw.util.addPortletLink('p-namespaces', '#', 'MISALIGNED');
});

I'd like to "bump" this task because it appears that the issue is still present in 2023.
Try the following link (the server domain, ja.wikipedia.org, should be modified if needed):
https://ja.wikipedia.org/w/api.php?action=query&list=globalallusers&agulimit=max&agugroup=founder%7Csteward%7Combuds%7Cstaff%7Csysadmin%7Cglobal-sysop%7Cabusefilter-maintainer%7Cabusefilter-helper%7Cglobal-interface-editor%7Cglobal-bot%7Cglobal-deleter%7Cglobal-rollbacker%7Cvrt-permissions%7Coathauth-tester&aguprop=groups&formatversion=2
Notice that agulimit is set to max. I have an admin right on jawp (hence have apihighlimits), then get 1467 responses, but when I open this link on an incognito window (meaning not logged in), I only get 500 responses (which is normal) and there's no continue property (which is abnormal).

A bit more information.
I tried erasing the relevant conditions that prevent account creations BEFORE forcible account creation, then that wasn't barred by the filter (note: I didn't either DISABLE or DELETE the filter). Maybe this is a workaround.
Anyway, when I forcibly created the relevant local account and blocked it for sockpuppetry with autoblock turned on, my IP was autoblocked. Is this normal? It's ridiculous that the IP of the sysop that took the admin action is autoblocked. Also, my IP will probably show up when the blocked user is CU-ed.

@Daimona Thank you so much for your detailed inspection, and

@Daimona It's fine, this would be time-consuming.
Our filters include both added_lines and removed_lines if they need to detect content addition/removal, so the false positives we came across are likely to be attributed to this bug.
Anyway, as I said above, we'd appreciate it if anyone could take care of this matter.

@Daimona Thanks for the quick response. I'm pretty sure this can make false positives (and in fact it did), so we'd appreciate it if anyone could fix it.

In T313661#8099586, @Dragoniez wrote:

But the blockID doesn't change even if the relevant user is reblocked

Sorry forget about what I said in the quoted part. This probably isn't the case because the logIDs of the blocks are different (6055924 (initial block), 6055931 (reblock)).

But the blockID doesn't change even if the relevant user is reblocked, so the alternative is perhaps not a very good idea. I'm just wondering whether that the timestamp doesn't get updated is a bug or intended.... and it seems like there's no way to get the reblock timestamp at present, using the action API.

@Umherirrender Just as I explained, but let's look at this:

Sorry I did something wrong.

@Xaosflux Yes, that's right. Just like "action=query&pageids=" and "action=query&revids=", this is what I'm looking for.

@Trizek-WMF, thank you for your reply again! And I'm sorry, I didn't know new accounts don't get notifications for reverts on jawiki and enwiki. Before I filed this (actually long ago), I took a look at ja:Wikipedia:通知, en:Help:Notifications, and mw:Help:Notifications/Types, but I only found "Received when your edits are undone or rolled back", and for this reason I had been thinking any account gets revert notifications when their edits are rolled back.

@Trizek-WMF, I think that that would involve some serious drawbacks, unfortunately. This is because new users and IP users would then need to do a manual revert any time when they want to revert others' edits, and the problem is that manual revert is way more complex than undo revert. Undo revert is very simple and straightforward because users just need to hit the undo link, but when you need to do a manual revert, you need to either first open a diff page and then do action=edit, or make exactly the same edit as the relevant previous revision. (And I'm pretty sure that even some extended-confirmed users don't know how to restore a previous revision from a diff.) Plus, the number of bad-faith edits is limited, and overall, undo reverts by new users are good-faith edits (like reverting vandalism edits). Disallowing undo reverts for new users would be easy because it can be achieved just by hiding the undo link for them via the CSS, but this is unlikely to be a solution for this matter, unfortunately.