Thanks @CC-TimidRobot!

Fix here: https://github.com/wikimedia/InteractionTimeline/commit/1817c2c780aaa886b7ae414adccd40b86a75de8c

@Niharika How important do you think it is to fix this?

@dbarratt You can this locally by enabling TorBlock, setting $wgTorDisableAdminBlocks = true and overriding TorExitNodes::isExitNode() to return true/false. It should then remove any non-user blocks, but keep any user blocks or composite blocks that contain user blocks.

For testing

@Niharika @SPoore Do you have any thoughts about @DannyS712's example?

Example for reviewing/testing/product input

@Krinkle Good to know for next time.

• The enableAutoblock widget is selected by default. Before the fix, it is still selected when hidden, and still therefore selected when it reappears. (The PHP knows to ignore it if the target is not of the correct type.) After the fix, it should not be selected when disabled, since this misleadingly implies that autoblocks will be enabled. However, when it is re-enabled it will still be unchecked. If this needs to be fixed, we might need to do something similar to the "Account creation" checkbox (T208510).

This applies to all the checkboxes. [...]

Thanks for the examples - we could try to address this while working on block error messages.

I think we should keep this open, because it is still technically possible to make this type of block with JavaScript disabled.

Here's the mobile block message task: T225939

I just realized that that page does not list the block id. :/ I wonder if it would be wise to add it to the BlockList and make that a url parameter?

Here are some screenshots of the block notice shown on trying to edit an article on desktop, after https://gerrit.wikimedia.org/r/520479. It now shows any relevant block IDs.

@RhinosF1 Thanks for the screenshots. It looks like the site is using MediaWiki version 1.33.0 (https://publictestwiki.com/wiki/Special:Version) - we fixed the checkbox to become disabled since then in T224032.

With JS, a number of checkboxes become disabled depending on the block parameters entered in the form. Obviously this doesn't happen without JS, which can make the experience misleading (e.g. T227199#5321559).

Without JavaScript it is possible for the form to be in a state where "Editing" is unchecked but "Editing their own talk page" is checked (and not disabled). In that case, we should probably throw an error instead of making the block.

@Jdlrobson Yes that should fix this - it hasn't been deployed yet, which is why the errors are still being logged.

There's a fix in master: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/519177/ It was tagged with T180050, which this task seems to duplicate (see above). Do you think we should backport that commit?

In T212326#5270394, @dom_walden wrote:

I notice on test.wikipedia.org, when there is a composite block blocking email, Special:EmailUser includes: "Block ID #".

This wasn't the case on beta.
@Niharika Should this be fixed as part of this bug, or raise a separate one?

@Krinkle Thanks for the verbosity.

From T226777#5293474:

This is similar to T180050. The problem is here:

@Niharika Not that I'm aware of, it just came up in code review because of the messages

@Niharika @dbarratt I have a question about how to display the list when there are a mix of local and global namespaces in the block.

@Niharika @dmaza There are a few places where the acceptance criteria don't match the behaviour of the patch (PS20). I suspect in some cases the acceptance criteria might just be old, so commenting here instead of in code review.

Steps to trigger the bug (needs $wgCookieSetOnAutoblock = true):

It seems worth fixing, since the block message will be more informative. In theory this problem could also arise in other ways; at the moment, autoblocks are only filtered out if they are found in the same database request as their parent block.

@dom_walden I think this bug probably doesn't cover these problems, since they both apply to the existing SystemBlock messages too. However, they should be fixed. Filed as: T225939

Thanks for reporting. It looks like it has been this way for a while (e.g. rolling back to 1.33.0, before the refactoring). @Niharika @SPoore would you have any concerns about allowing a user who is blocked from sending email to change their email address?

For testing/reviewing, this change affects:

• the error shown on trying to edit a page if at least one of the blocks applies to that page
• the error shown on Special:EmailUser if at least one of the blocks prevents email

@A2093064 The broken appearance of the page seems to be down to the MediaWiki:Group-sysop.js script.

(Didn't mean to remove the points value there, but since I did, replacing with something more accurate...)