This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

In T357118#9528544, @Xaosflux wrote:

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

I think if we had T352148: Blocks: add a structured category/reason field for cross-wiki use we'd at least be able to do things like "this block is targeting open proxies; prompt the user to disconnect from their VPN or request IP block exemption". That wouldn't cover all use cases, but presumably would handle a substantial percentage of block messages seen by good faith users. See also T357123: Implement Stewards/Wizard as instrumentable dialog about implementing an interactive dialog to guide the user through understanding the block and what their options are.

In T357118#9528544, @Xaosflux wrote:

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

I think this task is suggesting that there should be parity with the message shown on desktop?

In T357118#9528696, @kostajh wrote:

I think this task is suggesting that there should be parity with the message shown on desktop?

That certainly makes sense - is this not however already at least somewhat true or covered under another request?

Can someone show side by the the current MFE block message and the WEBUI block message for the same block? The initial user story seems to have picked a demo block that specifically doesn't include information.

In T357118#9528941, @Xaosflux wrote:

In T357118#9528696, @kostajh wrote:

I think this task is suggesting that there should be parity with the message shown on desktop?

That certainly makes sense - is this not however already at least somewhat true or covered under another request?

A while ago the AHT team did some work on mobile block messages (T190946), which partly involved simplifying them. But I've recently heard feedback from one of our directors who cited stewards raising this as an issue, which is why I filed the task (I've asked for more information to be shared on the task).

I couldn't find a task covering this, but we can merge this into another one if one is found.

Can someone show side by the the current MFE block message and the WEBUI block message for the same block? The initial user story seems to have picked a demo block that specifically doesn't include information.

This is still a local example, but this time I've added who to contact in the reason:

The desktop message comes with some extra info about how to get in contact (though the mention of email and preferences are actually not helpful to a logged out user, who doesn't have either), as well as what your IP address and block ID are.

@Tchanders and what happens when you click that "See details" button there in the MFE view?

In T357118#9528544, @Xaosflux wrote:

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

I think this is a problem with the naming of the task. The issue I raised in the Talking:2024 call was about composite blocks (see T344463) not showing properly on the Minerva skin.

If a user faces a local and global block, and is using Minerva, it is not possible for them to find the block reason.

E.g.:

First image is after attempting to edit, second is after clicking "See more".

When an admin or steward sets a block, we set a reason. That reason (whether it transcludes a large templates, includes a few links, or is just text) is the text that we want blocked users to see. From my perspective, there is no valid rationale to modify or simplify the reason that the blocking admin/steward sets. Especially when the current situation is simplified to a point of complete unusability.

That multiple block problem seems to be T233996 from 5+ years ago

I think this is a problem with the naming of the task.

Understood - I've renamed it, so hopefully that's clearer. Please feel free to rename it again if not.

We fixed this for Desktop in T349826: Show multiple block messages on UserBlockedError page by showing all the block reasons.

In T357118#9536082, @Xaosflux wrote:

@Tchanders and what happens when you click that "See details" button there in the MFE view?

FWIW See details links to Special:BlockList filtered to the block ID. But for composite blocks, the details link isn't there. I suppose another solution would be to link to Special:BlockList showing all the blocks, but I don't think that would help as some reasons would be displayed as templates.

I'd like to surface that this has continued being a big UX problem, and increasingly big ever since iCloud Private Relay has become more common to be enabled by default for Apple users.

There are many ranges that are hardblocked once for being in an e.g. Cloudflare range and are separately hardblocked another time for iCloud Private Relay (see this, for example). The second block can be helpful in pointing users to more specific guidance on what to fix, because it has an iCloud Private Relay-specific block message. But that now means many, many users see an utterly useless message when editing (see attached screenshots from someone who emailed me and imagine how frustrated one might feel as a blocked user). I don't know how many users experience this, but I imagine it's quite a lot.

I'd request that this get prioritized up the queue at T&S Product, with many thanks.

In T357118#11117495, @L235 wrote:

I'd like to surface that this has continued being a big UX problem, and increasingly big ever since iCloud Private Relay has become more common to be enabled by default for Apple users.

There are many ranges that are hardblocked once for being in an e.g. Cloudflare range and are separately hardblocked another time for iCloud Private Relay (see this, for example). The second block can be helpful in pointing users to more specific guidance on what to fix, because it has an iCloud Private Relay-specific block message. But that now means many, many users see an utterly useless message when editing (see attached screenshots from someone who emailed me and imagine how frustrated one might feel as a blocked user). I don't know how many users experience this, but I imagine it's quite a lot.

I'd request that this get prioritized up the queue at T&S Product, with many thanks.

As a starting point, we should pull information about how many users are encountering this UX.

In T357118#11117932, @kostajh wrote:

As a starting point, we should pull information about how many users are encountering this UX.

Linking also T396425: Update editattemptsblocked instrumentation for multiple blocks

This is still happening and is incredibly opaque when it does:

Is there actually a reason that we're not showing all the block-reasons? I appreciate it'd be an unfriendly UX to have a bunch of maybe-long template messages in that drawer, but anything would be better than the current situation.

Change #1245475 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] When a user can't edit because of a composite block, show the reasons

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

Okay, with that patch you'll still get the unhelpful initial view:

But if you tap "see more" it'll have all the component block reasons added in:

It will be less helpful in practice, because my local dev environment doesn't have the templates that're used for this which will take up a lot more space, e.g.

Change #1245475 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] When a user can't edit because of a composite block, show the reasons

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