Thanks for finding this.

I think this wouldn't have made sense <1.33 since that's when partial blocks was introduced, and the editing checkbox didn't exist before then. Only since partial blocks has it become theoretically possible to block someone only from their talk page.

Thinking about this, the problem is that the user talk checkbox is enabled when the editing checkbox is unchecked.

Since partial blocks ignore the ipb_allow_usertalk field, the only way apply a partial block to the target's own user talk page is to explicitly name it as a page restriction.

If the editing checkbox is unchecked, then the block must be a partial block, so the user talk checkbox should be disabled.

Change 512051 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Fix user talk checkbox enabling/disabling on Special:Block

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

How will this behave without JavaScript?

Without JavaScript, this behaves similarly to making a partial block against editing a page: the admin can check the user talk checkbox, but it won't have an effect.

I guess the form has quite a few checkbox options that are ignored for certain combinations of parameters, which is made obvious for users with JS but not without. They can at least follow the Help link at the top of the page.

Change 512051 merged by jenkins-bot:
[mediawiki/core@master] Fix user talk checkbox enabling/disabling on Special:Block

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

@Prtksxna I wonder if perhaps "Editing their own talk page" should be moved under "Editing" and changed to "Their own talk page"?

In T224032#5207879, @Tchanders wrote:

Without JavaScript, this behaves similarly to making a partial block against editing a page: the admin can check the user talk checkbox, but it won't have an effect.

I guess the form has quite a few checkbox options that are ignored for certain combinations of parameters, which is made obvious for users with JS but not without. They can at least follow the Help link at the top of the page.

Fair enough. This will also affect people submitting blocks via the API.

What I don't like about it is that, if I submit such a block, the Special:BlockList, Special:Log/block etc. report "cannot edit own talk page", even though that is not true. An admin might assume we support such a configuration, when we don't.

In T224032#5210078, @dom_walden wrote:

What I don't like about it is that, if I submit such a block, the Special:BlockList, Special:Log/block etc. report "cannot edit own talk page", even though that is not true. An admin might assume we support such a configuration, when we don't.

What happens in this scenario? Can you edit your own talk page or not?

Oh, nevermind, I remember why we did this, it's because there is no database flag for if it is editing or not. A non-editing block is an empty sitewide block (for now). If you would like to create a task for that, I can write what would be needed (a new field in the database to distinguish editing blocks for non-editing blocks).

Errr... well, I guess we could always fake it and use the same logic again, so if we know it's an empty partial block, then we can remove that from being displayed.

@dom_walden I agree - filed as T224468

Assuming this task is about the user management in MediaWiki core, hence adding MediaWiki-User-management so someone could find this task.

In T224032#5216247, @Tchanders wrote:

@dom_walden I agree - filed as T224468

Thanks!

"Editing their own talk page" checkbox only becomes enabled when selecting a sitewide block or a partial block with a namespace restriction to "User_talk".

We have not changed any of the behaviour of blocks, just the UI. So, further testing unnecessary.