Revert merged. (I just realized it wasn't tagged with this task, oops.)

The change caused T379983, reverted.

@Umherirrender found a bunch of problems in extensions reported by Phan due to the new type hints. A couple of them seem like real bugs that would have also caused warnings, but they mostly occur in rarely-reached error handling code paths. Fixes here: https://gerrit.wikimedia.org/r/q/topic:message-params-phan

WMF logs show one deprecation warning coming from EditPage::getPreviewLimitReport.

I think this can happen when the itr_transcludedfrom field (a foreign key to page.page_id) points to a page that has since been deleted.

The problem is that the visual diffs check for the 'stashbasehtml' permission. It is needed to open the page for editing (so to speak) in the visual editor, but not to view a visual diff. Unfortunately both "visual" things use the same API to access data. I feel like there's another bug about this somewhere.

@Tgr asked for review, and the query looks correct to me.

Somewhat familiar. If the question is can you add more information to that array, then I believe the answer is yes.

Looking at the current state of the files: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/9cdf8af39240b92258b78300bb8c6ff146626179/resources/src/mediawiki.special.apisandbox I think we can consider this done. The largest files are around 700 lines, which is maybe not great, but not too bad either.

FYI, jqueryMsg is basically a handwritten recursive descent parser. The example given in the Wikipedia article is perhaps a bit too complex to be educational, but knowing this keyword you can probably look up some other examples, and I hope this helps explain why all the functions exist and call each other like that. And the higher-order functions you mention are technically parser combinators (the example in this article is unfortunately even less educational).

That fixes the problem I encountered. I hope it's the same as yours.

Thank you!

These errors seem to have gone away. 🤷‍♂️

I kind of like this idea, there have been times where I had the option to do something in the interface, but I wasn't sure whether it was because of my local rights or the global interface-editor rights. That group comes with several broad permissions like being able to (un)protect pages, so I'm not always sure whether I'm supposed to be able to do the thing. I don't think I've made any edits I shouldn't have, but then, there's no way of knowing…

Thank you for your patches, everyone.

Thanks for that @Urbanecm_WMF.

Should be fixed for real this time. Thanks for the patch for this and the other issues, @Ammarpad.

This should be fixed in MediaWiki 1.43.

In T361775#9692580, @Nardog wrote:

@Esanders The patch does not seem to address the problem, which is not that the icons are missing but that these toggles appear at all.

There's a complaint about the removal of the options dialog for logged-out users at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Media_Viewer_can't_be_disabled_-_gear_is_gone.

I think that's all. Thanks everyone. This task could be made public now.

We could probably just deprecate it first:

		if ( !is_string( $whatever ) ) {
			wfDeprecatedMsg( __METHOD__ . ' requires a string, ' . get_debug_type( $whatever ) . ' given', '1.44' );
		}

Looks fixed to me.

@Reedy @sbassett Are you planning to submit Lucas's patch to Gerrit yourselves, or waiting for someone else to do it?

In T358779#10253027, @Nikerabbit wrote:

I'm seeing multiple of issues likely caused by this, e.g. T377917: Special:AbuseLog InvalidArgumentException when logged out, T377913: ApiHelp: PHP Deprecated: Use of "parent" in callables is deprecated

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1082102 would also have fixed this problem (I +2'd it last night, but it failed to merge due to some unrelated error).

I can't reproduce locally, but $diffLink in that code is initialized to false, so this should fix it. I think this is a pre-existing bug, and the stricter checks in my Message class changes just revealed it.

So, this is mostly my fault – while I knew how is_callable works in regards to autoloading, and I knew about similar issues caused by unserializing user input, I just never connected these two things in my mind as a potential security issue to look out for. I'm not sure if it is common knowledge.

Patch looks good to me. Sorry about that.

Everything looks as expected to me. I don't know what the problem two years ago could have been.

Now that the message parameters are ScalarParam objects rather than arrays, they need to be compared with == rather than === (or assertEquals rather than assertSame). I've made similar changes in MW core tests, I can make a patch for this too.

The change broke Flow, fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/1082002

You need to figure out if anyone other than me also wants to review the mobile login UX. If not, then it can be closed.

Lucky timing ;)

This is probably not needed these days. VisualEditor no longer introduces errors in articles, certainly not at a rate that would demand a prominent action to report them.

Copying a possible solution from the Gerrit discussion:

That's neat, I like it.

I can't reproduce any of the problems today.

Do you only see this problem on talk pages? I've experienced something similar with articles, where if my mobile connection is poor, the article sections sometimes don't expand.

It looks like it should work… I can give it a try.

You'll need to make sure that your MediaWiki and your VisualEditor are compatible versions. You say you've installed MediaWiki 1.41.1, but the VisualEditor version you downloaded is for MediaWiki 1.42. Try choosing 1.41 from the dropdown at https://m.mediawiki.org/wiki/Special:ExtensionDistributor/VisualEditor and try again.

It doesn't look like anyone is going to work on this. Instead see: T328962: Create a public visualization that enables people to see and monitor DiscussionTools usage across time

I couldn't reproduce this at first – special page transclusion does not result in those links being shown. I eventually figured out that the links are produced by Scribunto's mw.title getContent() method. I think that's the real bug here, and I filed a task about it: T377530: Scribunto mw.title getContent() method can record templatelinks to special pages (but I still approved your patches here, as it seems reasonable to handle this case – maybe recording special page transclusions is made to work one day, or maybe no one ever fixes that Scribunto bug).

In T310274#8013516, @stjn wrote:

As I noted in T117754#8013510, the form should just not be collapsible. There is practically no benefit to it, and it makes using the page a bit harder. If the developers listen to this, then this task could be resolved for all intents and purposes.