Seems to also happen for mediawiki.org.
Does not happen on test.wikidata.org.

Network connection stack trace:
...
https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?type=script&wikiid=wikidatawiki&mobile=1&proto=https&mobile=1
https://www.m.wikidata.org/wiki/Special:CentralAutoLogin/createSession?token=...&type=script&proto=https&mobile=1

I believe (but I do not claim to be right on this one) the issue happens inside https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/e7ff08db5325ba0d1a4728dcc3d70df06a0cec7f/includes/specials/SpecialCentralAutoLogin.php#L608-L625

Not very extensive testing around MobileContext::getMobileUrl has not identify issues over there. Current working hypothesis of mine is that it is WikiMap::getForeignURL what adds the superfluous www. to the URL.

Would be great to get word from the MediaWiki-extensions-CentralAuth people if they have a suspicion where this problem originates from.

Pinging maintainers according to https://www.mediawiki.org/wiki/Developers/Maintainers: @hoo, @vvv, @csteipp, @Legoktm: any idea why mediawiki.org and wikidata.org might behave special (and arguably incorrect)?

It is a bit concerning to see this has not been triaged by the maintainers after more than 3 weeks.

Also going to tag MediaWiki-Core-AuthManager as it could be related and likely to catch some more eyes.

My hunch would be that this has to do with the CA cookie domain for things like wikipedia being set to ".wikipedia.org" but the domain for wikidata gets set to "www.wikidata.org".

Which would mean this related to wgCentralAuthLoginWiki which is documented on https://www.mediawiki.org/wiki/Extension:CentralAuth and also our default settings for that var which can be found in InitialiseSettings.php

		'.wikipedia.org' => 'enwiki',
		'meta.wikimedia.org' => 'metawiki',
		'.wiktionary.org' => 'enwiktionary',
		'.wikibooks.org' => 'enwikibooks',
		'.wikiquote.org' => 'enwikiquote',
		'.wikisource.org' => 'enwikisource',
		'commons.wikimedia.org' => 'commonswiki',
		'.wikinews.org' => 'enwikinews',
		'.wikiversity.org' => 'enwikiversity',
		'.mediawiki.org' => 'mediawikiwiki',
		'www.wikidata.org' => 'wikidatawiki',
		'species.wikimedia.org' => 'specieswiki',
		'incubator.wikimedia.org' => 'incubatorwiki',
		'.wikivoyage.org' => 'enwikivoyage',

Needs a bit more investigation thoguh

@Anomie could you review this and give an opinion on who would be best/which team to request input from?

This has nothing directly to do with CentralAuth. The logic that mangles URLs for mobile domains belongs to MobileFrontend, specifically it's in MobileContext::getMobileUrl() and its downstream methods.

anomie@mwmaint1002:~$ mwscript shell.php --wiki=enwiki
Psy Shell v0.9.12 (PHP 7.2.26-1+0~20191218.33+debian9~1.gbpb5a340+wmf1 — cli) by Justin Hileman
>>> $wiki = WikiMap::getWiki( 'wikidatawiki' );
=> WikiReference {#5960}
>>> $url = $wiki->getFullUrl( 'Special:CentralAutoLogin/start' );
=> "//www.wikidata.org/wiki/Special:CentralAutoLogin/start"
>>> MobileContext::singleton()->getMobileUrl( $url )
=> "//www.m.wikidata.org/wiki/Special:CentralAutoLogin/start"

Digging a little deeper, it seems to assume that every URL being mangled can use the local value for $wgMobileUrlTemplate rather than determining the mangling based on the target domain.

Poking to Web-Team-Backlog as the owner of MobileFrontend.

In T225814#5992589, @Anomie wrote:

Digging a little deeper, it seems to assume that every URL being mangled can use the local value for $wgMobileUrlTemplate rather than determining the mangling based on the target domain.

On that note, it may be causing problems in links out of wikidata.org and similar domains too:

anomie@mwmaint1002:~$ mwscript shell.php --wiki=wikidatawiki
Psy Shell v0.9.12 (PHP 7.2.26-1+0~20191218.33+debian9~1.gbpb5a340+wmf1 — cli) by Justin Hileman
>>> $wiki = WikiMap::getWiki( 'enwiki' );
=> WikiReference {#2944}
>>> $url = $wiki->getFullUrl( 'Special:CentralAutoLogin/start' );
=> "//en.wikipedia.org/wiki/Special:CentralAutoLogin/start"
>>> MobileContext::singleton()->getMobileUrl( $url )
=> "//m.wikipedia.org/wiki/Special:CentralAutoLogin/start"

Thanks @Anomie !

This is not a MobileFrontend issue TBH.

On wikidata.org (wmf-config/InitialiseSettings.php) $wgMobileUrlTemplate is set to m.%h1.%h2

		$url = MobileContext::singleton()->getMobileUrl(
			wfAppendQuery(
				"//www.wikidata.org/wiki/Special:CentralAutoLogin/start",
				[]
			)
		);

gives "//m.wikidata.org/wiki/Special:CentralAutoLogin/start"

The only way I seem to be able to get https://www.m.wikidata.org/...%22 is if I pass in "https://m.www.wikidata.org/wiki/Special:CentralAutoLogin/start" which is garbage in.

Although that works fine if I call that function with other projects, I'm going to get bad results. For example on English Wikipedia $wgMobileUrlTemplate is set to '%h0.m.%h1.%h2'. so if you call getMobileUrl on a wiki with a different host you are going to have a bad time.

The issue should be resolved in CentralAuth (I'm not sure who maintains that) however I'm not quite sure how this will work.

The hook in MobileFrontend GetMobileUrl could be used or alternatively CentralNotice could make use of Varnish/redirects to determine what these links should be.

Note:
I remember vaguely working on a similar bug several years ago with help from the security team that introduced the hook GetMobileUrl. We use to have a GetMobileUrl hook somewhere in our codebase, but that seems to have disappeared so that might provide further clues on how this broke.

Thanks @Jdlrobson for your elaboration.

The issue should be resolved in CentralNotice (I'm not sure who maintains that) however I'm not quite sure how this will work.

Did you mean CentralAuth, or actually CentralNotice? (First time Central Notice is mentioned in this context, hence I felt like I'd double check)

Sorry Centralauth my bad. Always mixing up those 2.

T214998: RFC: Remove .m. subdomain, serve mobile and desktop variants through the same URL would render this obsolete (but pose different challenges, no doubt).

FWIW I can't see T214998 happening any time soon. As far as I can see that's a product decision and I'd recommend reaching out to Jon Katz or Olga Vaseliva if you need a more accurate update on the state of that task.

Is this a dupe of T239669?