This problem has also been mentioned here.

In T255383#6358474, @DannyS712 wrote:

In T255383#6358411, @Ahmad252 wrote:

In T255383#6357946, @DannyS712 wrote:

In T255383#6357656, @Ahmad252 wrote:

In T255383#6224632, @Daimona wrote:

In T255383#6224436, @DannyS712 wrote:

In T255383#6222979, @Daimona wrote:

In T255383#6222547, @DannyS712 wrote:

You can use '\nconfirmed' in user_groups

That wouldn't work if 'confirmed' is the first group though (unsure if possible right now). Using user_groups rlike "(?<!auto)confirmed" seems more future-proof. But yes, the only real solution is to implement array functions.

I've always seen * as first, and then user, and then any other groups, but I'm no expert

Same, but what I meant is, there's no guarantee that it'll always be like that -- the order is controlled by core and should not be relied upon.

This actually happened on fawiki earlier today: here.

That filter entry is private - can you paste what the order was?

Sure. It's:

[
	0 => 'confirmed',
	1 => '*',
	2 => 'user',
	3 => 'autoconfirmed'
]

Hmm, so confirmed was prepended, and then the rest were normal? Has this occurred elsewhere?

Precisely. I haven't seen any other examples, but it's worth noting that the "confirmed" flag is not usually granted to users on fawiki, so I don't exactly know if this is a rare exception or not.

In T255383#6357946, @DannyS712 wrote:

In T255383#6357656, @Ahmad252 wrote:

In T255383#6224632, @Daimona wrote:

In T255383#6224436, @DannyS712 wrote:

In T255383#6222979, @Daimona wrote:

In T255383#6222547, @DannyS712 wrote:

You can use '\nconfirmed' in user_groups

That wouldn't work if 'confirmed' is the first group though (unsure if possible right now). Using user_groups rlike "(?<!auto)confirmed" seems more future-proof. But yes, the only real solution is to implement array functions.

I've always seen * as first, and then user, and then any other groups, but I'm no expert

Same, but what I meant is, there's no guarantee that it'll always be like that -- the order is controlled by core and should not be relied upon.

This actually happened on fawiki earlier today: here.

That filter entry is private - can you paste what the order was?

Sure. It's:

In T255383#6224632, @Daimona wrote:

In T255383#6224436, @DannyS712 wrote:

In T255383#6222979, @Daimona wrote:

In T255383#6222547, @DannyS712 wrote:

You can use '\nconfirmed' in user_groups

That wouldn't work if 'confirmed' is the first group though (unsure if possible right now). Using user_groups rlike "(?<!auto)confirmed" seems more future-proof. But yes, the only real solution is to implement array functions.

I've always seen * as first, and then user, and then any other groups, but I'm no expert

Same, but what I meant is, there's no guarantee that it'll always be like that -- the order is controlled by core and should not be relied upon.

I remember a similar issue reported on Persian Wikipedia around August 2019 (many users experienced it, only when using Visual Editor). At the time, it was limited to Persian Wikipedia, but I think no one never reported it here. Maybe it's been caused by something deeper?

You may find the ng version useful as a temporary solution.

I think this should be granted to all users with the ability to block users (with extra features for CheckUsers that should be discussed in Special:InvestigateBlock-related tasks). We already have User:Timotheus Canens/massblock.js that does the very same thing. I have not tested the script yet, but the fact that it exists (and has been listed on Wikipedia:Administrators' guide/Tools) suggests that we can trust administrators with a massblock function.

In T249565#6034523, @DannyS712 wrote:

In T249565#6034514, @Ahmad252 wrote:

+ Now on Commons; e.g. on https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:صورة_شخصية_له.jpg.

The common page worked for me though

+ Now on Commons; e.g. on https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:صورة_شخصية_له.jpg.

When thank isn't sent for non-AF reasons, I think there should be a notification like the one we see when a ping is unsuccessful, with a gray "File:OOjs UI icon userTalk-(ltr|rtl).svg". When it's been blocked by AF, there should be a red warning instead of "You thanked $1" (MediaWiki:Thanks-button-action-completed) that says e.g. "Your thank was not sent because it was blocked by the abuse/edit filter", but this should be the default warning. Just like the warn/disallow feature, this message should be editable, by creating a new page in the MediaWiki namespace. In my opinion, this is a rather clean way to implement it.

Note that after logging in to your account, it will follow your preferences and the issue will be resolved. This particularly damages the user experience of anonymous readers. Both mobile and desktop versions have the problem.

I think you can do this with a trick. On all wikis, you can go to Special:AbuseFilter/tools and write something like this:

How about this: We can add all those pages to a maintenance category like "Category:Partial block of User:Example from PROJECTNAME". In Commons, for example, it would be "Category:Partial block of User:Example from (Wikimedia) Commons". Then, we can set an edit filter to prevent all users but admins from adding or removing this category from all pages (possible using a simple regex). A better solution would be a built-in feature to prevent all users but admins from adding/removing the category. I really see no other way.

Hi, what is the underlying use case for that?

Hi. One situation can be when you want to find behavioral similarities between a number of users. For example, you want to see if they've inserted the same suspected text in different articles or not.
Another situation can be searching your own contributions. This can be useful, especially when working with stats. Imagine you want to find out how often an admin notifies the blocked user from the block, or you want to check for all public domain images uploaded by a user etc. I can think of some project-specified uses as well, such as the number of license reviews a Commons license reviewer has done. If these examples aren't enough, I can think of some other ones.
Nonetheless, I can think of technical limitations.

+1. It must be some kind of incompatibility with undo. I tried safemode as well, doesn't work with undo. I also tried using a script which uses undo to restore the page to a specific revision, doesn't work.

I can reproduce it here in chrome v76, and I know at least one user in fawiki having the same problem. Again (like T232085), it only occurs in chrome and only in RTL languages. The menu is still there, however. If you click on that blank space before the logo, it will open the menu properly.

@Ladsgroup There is this .mw-tag-markers::after, I think it is the one responsible for that (. To be honest, it's somehow confusing since it contains exact the same thing in Firefox and Chrome:

Update: I experienced no problem in a firefox-based browser and Microsoft Edge works fine as well. Despite this, I checked Google Chrome in different situations, no luck.

It's not just RC, I experience this problem in history and contribs as well. I checked contributions of a user in arwiki, and I only got this, just like fawiki:

@Aklapper Hi, I just edited the task with more detailed info. Thanks for pointing it out.

I'm not sure, let me ask others in fawiki.

Sure, here:

That's "rollback" button (which is only visible to rollbackers and sysops). However, I tried while logged out, the problem was still there.

No luck, I still have this problem. This is the exact address of RC I'm looking at. I think it isn't caused by a gadget or something since I checked fa, ckb and arwiki, all have this problem.

I personally use Chrome, don't know about the others. Here's the screenshot:

Works fine in fawiki.

Same problem in Persian Wikipedia (fawiki): https://fa.m.wikipedia.org/wiki/Special:ContentTranslation.

In translations, could you please change "نجات {linksrescued} و علامت‌زدن {linkstagged} به‌عنوان مرده." to "نجات {linksrescued} منبع و علامت‌زدن {linkstagged} به‌عنوان مرده."? (It's the translation of "Rescuing {linksrescued} sources and tagging {linkstagged} as dead.
") It was my translational mistake. Also, is it possible to use ۱۲۳۴۵۶۷۸۹۰ instead of 1234567890 in edit summaries? Thanks.
Update 1: Since using {{Wayback}} in both English and Persian references would cause some problems, I also created {{وی‌بک}} for Persian links. Can you specify {{Wayback}} to non-Persian links and {{وی‌بک}} to Persian ones?

Hello again. Thanks for your efforts. I just ran IABot in here and here, I must say it works like a charm. Please inform me whenever the development is completely finished because I haven't yet informed fawiki users. Thanks again.
Update: As I checked now, bot queue is disabled for fawiki.

• We have {{deadlink}} and {{پیوند مرده}}, first one is a redirect to {{پیوند مرده}}.
  • Actually, I didn't get the point about archive templates. If it's {{Webarchive}}, yes we have it ({{Webarchive}} in fawiki)
  • Yes, we do.
  • Typical date format is DDMMYYYY (like 19 May 2019).
  • We have {{cite}} templates and {{یادکرد}} templates. For {{cite}}, it's the same as enwiki. for {{یادکرد}}, we have {{یادکرد}}, {{یادکرد خبر}}, {{یادکرد کتاب}}, {{یادکرد ژورنال}}, {{یادکرد وب}}, {{یادکرد دانشنامه}}, {{یادکرد روزنامه}}, {{یادکرد ویدئو}}.