(All this also applies to T276147. Only responding in one place.)

See T276149#7144054. (Should these tasks be merged...?) With 2.7.50362-beta-2021-06-04, the block message is there now, but it's not parsed. @Dbrant implied there might a newer version that does parse the message, but I can't find it.

@Dbrant: That link is a 404 but I tested on 2.7.50362beta-2021-06-04, which is the latest on https://releases.wikimedia.org/mobile/android/wikipedia/betas

! In T276149#7122539, @Dbrant wrote:

Tested in 2.7.50359-alpha-2021-05-27 on testwiki

Tested in 2.7.50359-alpha-2021-05-27 on enwiki

So it seems that the only kind of block that gives me any details is a global block:

I tried on a few random IPs, and most of the time I saw a (correctly parsed) block message. But once I saw a message claiming that my user account had been blocked. No, I didn't write down the IP; sorry.

The problem still exists for me, with 2.7.50358-r-2021-05-11.

@Dbrant: Try making any edit to https://en.wikipedia.org/wiki/Wikipedia:Edit_filter/Message_tests. Filter 1147 will disallow all edits to that page, (currently) with the default disallow message.

Tested with 2.7.50357-alpha-2021-05-10.

Could it be this?

	if ( $user->isAnon() ) {
		$conds[] = 'actor_name<>' . $dbr->addQuotes( $user->getName() );
	} else {
		$conds[] = 'actor_user<>' . $dbr->addQuotes( $user->getId() );
	}

But the API seems to work:

This also happens at Special:RecentChanges and Special:Special:RecentChangesLinked. https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&hidemyself=1&days=30 and https://en.wikipedia.org/w/index.php?title=Special:RecentChangesLinked&hideliu=1&hidemyself=1&days=30&target=Main_Page show me nothing at all, for example.

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

Getting the same thing on enwiki, try https://en.wikipedia.org/api/rest_v1/page/mobile-html/Wikipedia:Administrators'_noticeboard%2FIncidents

I just tried leaving a message on my IP's talk page. I was using app version 27.50341-r2021-02-02. I got no alert.

Also partial blocks give the same "Your user account has been blocked from editing on this wiki". There is no indication that it's a partial block, and the user can edit other pages. Not sure if that should be a separate task.

Yes. What other app can be used to edit enwiki?

@sbassett: I thought the idea was to have canTestTools(), in the future, also allow users some new right (abusefilter-test, etc.). If that's done, then users with that new right will also be able to view private filters, with an URL like the one above.

As a reminder, Special:AbuseFilter/test still allows you to view private filters with a URL like https://en.wikipedia.org/wiki/Special:AbuseFilter/test/2.

That was quick! Probably should have said that the new "live" syntax checker is a really great improvement; thank you for implementing that!

The problem is gone for me on enwiki. And the Ace editor now warns me about invalid syntax. Thanks!

In T271487#6730311, @Daimona wrote:

So it's this line.

Malformed URIs occur when you run encodeURIComponent on something that cannot be encoded.

Instead of a rate limit, what if unprivileged uses of /test were limited to at most N cores and M bytes of memory? Then the only "service" anyone could "deny" is /test itself, which doesn't seem like a worthwhile target. Something similar is done with regex and Special:Search, if I recall.

In any case, if I am correct, then we could just set a per-IP limit for the badoath action, which would then be counted across all wikis.

I also get a captcha request if the string tel:// is already on the page. See https://en.wikipedia.org/w/index.php?title=User:Suffusion_of_Yellow/CaptchaBug&diff=968045535&oldid=968045267.

Does this still need to be private?

@tstarling: I just set enwiki filter 68 to exclude bots.

It looks like the only actions that are disabled by default are block, rangeblock, and degroup. The reason blockautopromote is available on enwiki is that no one's ever explicitly disabled it with $wgAbuseFilterActions['blockautopromote'] = false;, yes? The question is, do we need "community consenus" to get that line added, given that AFAIK no one has used that option in years on enwiki?

Marking this as low priority for now. @suffusion_of_yellow - could you expand a bit on why you think that the red circle is not a good enough indicator? I agree that we are most definitely not a social media site, but regardless I think it's an effective way to notify.

In T240889#5752169, @Xaosflux wrote:

@suffusion_of_yellow regarding "range talk", lets assume for a moment that it did exist - how would you expect notification/clearing of such a notification to function?

In T240889#5751876, @Aklapper wrote:

I'm curious how high the rate of IP users is that are not ignoring "their" talk page. Especially if they don't have a static IP. (Anybody having any numbers?)

@ovasileva: Why was this one marked low priority? I understand that people might disagree with me about T240976, and I'll respond to your question there later, but this one's a big deal. We literally have no way whatsoever to initiate a discussion with logged-out mobile users. Worse, we think we're talking to them.

@Xaosflux: Thanks! I consider the IP issue a high priority problem, the logged-in issue less so. I had assumed that the goal had been to deliver the banner to all users, in one form or another (as on desktop), and a simple bug was preventing the display. Now that I know that part of this is intentional, I will split the task.

@Ammarpad: I only see the red circle when I'm logged in. I see no indication of any kind that there is a message, when logged out. Do you?

In T240889#5745757, @Aklapper wrote:

If this ticket is about the lack of a "You have new messages" banner in the mobile interface for logged out users, then I do not see any bug here. Not sure as the steps are confusing and don't explicitly list an expected and an actual outcome, and if that was in mobile or desktop or in that one window or that other window.

In T240889#5745743, @Aklapper wrote:

@suffusion_of_yellow: Is one of these browser windows in private mode, or not?

Certainly seems resolved on enwiki. I re-enabled the filter in the task, and there were no hits in about a day. Thanks!

It's a good default to try to find and test vulnerabilities like this locally, but again, sometimes that's just incredibly inconvenient or even impossible and so discreet testing somewhere like the testwikis becomes the only viable option to fixing these vulnerabilities.

How do I find out if an XSS impacts production? I don't want to save anything like that on testwiki, even if I delete it one minute later.
Anyhoo, this page works for me even with $wgFragmentMode = [ 'html5', 'legacy' ];:

User-agent Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
MediaWiki 1.35.0-alpha (fdfa0e9)
MobileFrontend 2.1.0 (a812ef8)

Haven't tried to set up the 2017 editor locally. That means installing VE first, yes?

Could varnish be doing something with the line endings? I'm in the US, so we are probably connecting to different datacenters.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

I just realized that almost all of those edits were saved, and _lines variables are just unavailable.

Reproduced on testwiki, again with the 2017 editor: See https://test.wikipedia.org/wiki/Special:AbuseLog/55835. The some content triggered this on enwiki; see https://en.wikipedia.org/wiki/Special:AbuseLog/25537680.

For Special:AbuseFilter/test: yes, that's "intended" and there's not much we can do. That page allows testing a filter against recent changes, not AbuseLog entries. If you want to forbid testing a suppressed AbuseLog entry, you should also suppress the corresponding revision (which is usually done, AFAIK). /test has no knowledge about the AbuseLog, so there's nothing we can do about that.

Ok, that explains 25321331. I also don't see tboverride in user_rights, so it looks like GorillaWarfare didn't grant Huggle editprotected rights. This can probably be closed as invalid, but 'll leave that to Daimona.

@JJMC89: That makes sense, in theory. But is it really impossible to edit EC-protected pages from Huggle? If not, EC should still be part of the rights.

Original discussion here (PermaLink).

@Urbanecm: That was quick! Your commit message says users can "view any version of any filter", but the problem isn't that severe. Only old public versions are visible, which is only a problem when filter managers tick the wrong box. At least, I get an error for: