@Niharika Yes that's fine

I've updated the description to go into more detail about some of the problems with the partial block message.

@dom_walden The block message for Special:EmailUser is pretty broken... Before this task, if one of the blocks is sitewide the message looks like this:

• If you are logged in with an autoblock against your username, when you log out the block cookie is immediately removed. Previously, the cookie would remain, even after you perform a blockable action (e.g. editing). This seems to be a regression.

@Niharika We should be able to close T227901 once all WMF sites are on 1.35.0-wmf.1. The logs will still be recording that warning until then.

@Krinkle Sorry should have clarified - this should be fixed in 1.35.0-wmf.1

@Niharika That's an interesting point.

@Niharika Thanks for providing the alternative perspective.

@Niharika I'd argue that the behaviour should be changed.

@Niharika should block cookies be a rolling 24 hours or a should it be a hard 24 hours? Right now, the block cookie is set for 24 hours, and regardless of how many attempts you make, it will expire in 24 hours. With this change, if you make an uncached request to MediaWiki, the block cookie expiration will be reset.

This should be fixed since https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/534933/ which removed the DeferredUpdates from the BlockManager.

Just re-opening this until signed off by QA

@dbarratt Yes - tagged.

@dbarratt It will expire, but the block may be removed first.

The problem seems to be that only the global block is being reported, but not the local block (e.g. see the reported blocker name).

I believe my argument for that patch was that cookie blocking should be a standard feature and thus be enabled by default in core.

@dmaza - do you have any thoughts on changing the config back to false in core?

@DannyS712 Thanks for pointing out that task. (See T233441#5513467 - the problem is with cookie blocks and won't affect users on different devices.)

Thanks for reporting - this appears to be happening because of cookie blocks rather than autoblocks. Following the steps locally, I find:

• the sysop is only blocked if cookie blocks are enabled ($wgCookieSetOnAutoblock = true)
• the sysop sees the same block message as the blocked user, rather than the autoblock message
• the block ID cookie is set

I think the question of whether a logged-in user is ever expected to be blocked by an IP block on office wiki is relevant: if the answer is no, then the 'ipblock-exempt' right should be granted to all users, regardless of this task (and then the problem that this task is trying to fix would be solved).

@Tchanders you're making a good point about this; however, this will only fix the underlying ask tangentially. It would mean that the checkbox being selected won't matter, but it won't actually unselect that checkbox.

@Volker_E Are there any accessibility reasons for recommending enable/disable over hide/show?

I agree that it feels a bit problematic to make assumptions about autoblocks based on the $wgBlockDisablesLogin config. I'm not sure I agree the checking of $wgBlockDisablesLogin and isEveryoneAllowed('read') is much better - it's less impactful, but the principle is the same. (If a wiki with these settings wanted the checkbox checked by default, what would we do?)

@Anomie That's correct - thank you for summarising so clearly for future readers of this task.

In T233119#5501256, @Reedy wrote:

I think this task is done, and we don't actually need to re-instate https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/534707/ as the behaviour is now as expected?

@Tgr OK, it sounds like we should be doing #2 then, but leaving MinimumPasswordLengthToLogin alone instead of discarding?

• PasswordPolicyChecks::checkMinimumPasswordLengthToLogin calls Status::fatal (sets Status::ok to false).

Been looking into this with @dmaza - seems to be a difference in the type of status returned by the checks for the different policies:

• PasswordPolicyChecks::checkMinimalPasswordLength calls Status::error
• PasswordPolicyChecks::checkMinimumPasswordLengthToLogin calls Status::fatal (sets Status::ok to false).

@daniel - see T231930#5496232

In T231930#5495724, @daniel wrote:

T196575: Add block cookie for browser-based API edits (including VisualEditor & MobileFrontend) seems to indicate that we need to be able to manipulate the response (cookies) from the context of block management as well.

In T196575#5472917, @Krinkle wrote:

Calling trackBlockWithCookie() as standard part of pre-shutdown on web requests will:

• [...] Let getUserBlock remain predictable (no side-effect), and keep BlockManager separate from implicitly depending on WebResponse or otherwise making it unsafe to use post-send or outside web requests.

Thanks everyone.

But, it will change the behaviour of default installs.

It sounds like the following would be a better approach:

• If the user is unblocked, block them with the hidden SystemBlock
• If the user is blocked, add the hidden SystemBlock to any existing blocks as a CompositeBlock (instead of overriding)

The error messages are fairly inconsistently located on Special:Block... These error messages are also located at the top (and only the first one encountered will be displayed):

• already blocked
• hide user with the wrong settings (e.g. with finite duration)
• entering a time in the past in the expiry widget text input

Saw this task too late, but should be fixed by: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/531270/

Thanks @CC-TimidRobot!