FWIW this code block also looks suspect:

if ( mw.user.isAnon() && Array.isArray( editRestrictions ) && editRestrictions.indexOf( '*' ) !== -1 ) {
	bindEditLinksLoginDrawer( router );
} else {
	var $link = $( '<a>' ).attr( 'href', '/wiki/' + mw.config.get( 'wgPageName' ) + '?action=edit' );
	editErrorMessage = isReadOnly ? mw.msg( 'apierror-readonly' ) : mw.message( 'mobile-frontend-editor-disabled', $link ).parseDom();
	bindEditLinksSorryToast( editErrorMessage, router );
}

I don't think there's any situation where you could circumvent an editing restriction by signing up (the weakest protection level is autoconfirmed, except on those wikis which disallow IP editing, but those use a JS hack so wgRestrictionEdit will be still empty), and it's impossible to guess what rights the user will have when logged in, so a login button will always be useful and a signup button will never be (for the purposes of immediate editing).

Change 824322 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/MobileFrontend@master] Do not change mw.config.get('wgRestrictionEdit')

https://gerrit.wikimedia.org/r/824322

In T315518#8164015, @Tgr wrote:

FWIW this code block also looks suspect:

if ( mw.user.isAnon() && Array.isArray( editRestrictions ) && editRestrictions.indexOf( '*' ) !== -1 ) {
	bindEditLinksLoginDrawer( router );
} else {
	var $link = $( '<a>' ).attr( 'href', '/wiki/' + mw.config.get( 'wgPageName' ) + '?action=edit' );
	editErrorMessage = isReadOnly ? mw.msg( 'apierror-readonly' ) : mw.message( 'mobile-frontend-editor-disabled', $link ).parseDom();
	bindEditLinksSorryToast( editErrorMessage, router );
}

I don't think there's any situation where you could circumvent an editing restriction by signing up (the weakest protection level is autoconfirmed, except on those wikis which disallow IP editing, but those use a JS hack so wgRestrictionEdit will be still empty), and it's impossible to guess what rights the user will have when logged in, so a login button will always be useful and a signup button will never be (for the purposes of immediate editing).

I think this is correct, and it's intended for our "fishbowl" wikis (where everyone can read, but account creation is restricted and only registered users can edit). In this case mw.config.get( 'wgIsProbablyEditable' ) will be false, but mw.config.get( 'wgRestrictionEdit' ) will be empty. (There may be other reasons for that, but I guess we're choosing not to worry about that.)

Example: https://am.m.wikimedia.org/wiki/Նախագծեր/Վիքիճամբար

Reproduce locally with these settings:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

As it happens, this code is actually not working for unrelated reasons: T315683. But if it worked, it would be fine IMO.

In T315518#8169538, @matmarex wrote:

I think this is correct, and it's intended for our "fishbowl" wikis (where everyone can read, but account creation is restricted and only registered users can edit).

It's true that the editRestrictions.indexOf( 'user' ) check won't work on fishbowl wikis, as editing is limited via the permission system, not the restriction system. If we wanted to keep the code functionally equivalent after fixing the bug with *, the right check for that would be editRestrictions.length.

But I think in general what I wrote still stands: the signup button never helps (it won't even work on fishbowl wikis), and you can never tell whether the login button helps (the number of people who could become able to edit an enwiki autoconfirmed-protected article by logging in is actually far larger than the number of people who could become able to edit a fishbowl wiki page by logging in). So I think you should either always show the drawer (and get rid of the signup button), or add a login link to the sorry toast, or just not show a login link ever (it's in the hamburger menu anyway). Trying to do different things based on protection level just doesn't add any value.

If you'd like to delete all of this custom logic and messages, and replace it with whatever message MediaWiki usually shows, I completely support that. However, it should not be a part of this bug fix.

Change 824322 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Do not change mw.config.get('wgRestrictionEdit')

https://gerrit.wikimedia.org/r/824322