Page MenuHomePhabricator

Better handle block reasons on mobile (specifically templates and HTML comments)
Open, MediumPublic


T165535 improved the UI of blocks on mobile, but blocks with templates as their block reasons are still troublesome.

Reason for the block
{{anonblock}}: <!-- IP hoping vandalism and disruption: LTA -->

This does not accurately provide the user with the block rationale.

Proposed Solution

Alternative Solution

Limit block comments to simple summary parsing (i.e. links). People should not be putting tables and templates into block comments. If they need to include detailed information, they can link to a wikipage.

See T165535#4038869 for more discussion on this topic.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Lofhi awarded a token.Oct 23 2018, 1:31 PM
JJMC89 renamed this task from Better handle template block reasons on mobile to Better handle block reasons on mobile.Nov 5 2018, 3:47 AM
JJMC89 updated the task description. (Show Details)
JJMC89 added a subscriber: JJMC89.

I would like to see the reason parsed so that

  1. HTML comments are not shown
  2. and templates are displayed or clickable to display (over the drawer?). (The template should display as it would appear on the page where the user sees the block.)
TBolliger renamed this task from Better handle block reasons on mobile to Better handle block reasons on mobile (specifically templates and HTML comments).Nov 5 2018, 5:09 PM

Renaming to be more specific, for searchability.

  1. I agree.
  2. Most block warning templates are designed for desktop and do not display appropriately on mobile. I don't think they should appear directly in the drawer, but perhaps could be expanded on tap. We'll want to rope in a UI designer to help with this.
Jdlrobson added subscribers: alexhollender, Jdlrobson.

@TBolliger shouldn't this be tagged anti-harassment? Sorry if I'm missing something. Are you looking for input specifically from @alexhollender ?

@TBolliger I'm still confused. This bug was raised by you and my team isn't planning to work on this but it's been marked as "tracking work by other teams". Please let me know if you're expecting something from us here.

I'm not expecting anything from your team and I cannot prioritize this for my team either. It sounds like neither team is planning on working on this in the foreseeable future. No surprise — it will require a lot of work to very little end-user benefit.

Thanks for the clarification @TBolliger ! understood! It will indeed!

Some possible ways to solve this:

  1. Strip templates and/or comments
  2. If the reason has a template or a comment, do not show the reason
  3. If the reason has a template or a comment, replace with a "probable match" reason (e.g. {{spam}} to Inserting spam)

Comments should be stripped. If templates cannot be displayed, then a link to the user's talk page is better than nothing. Details won't always be on there though (e.g. IP range blocks).

Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptMar 29 2019, 6:46 PM

Summarising my comments from T219661:

On Special:Blocklist we use the commit message parser which only allows links and comments:

{{echo|Template}} [[reason]] ''italics'' '''bold''' you're blocked! /* comment */

On desktop we use the full parser and this is widely used to show reason information. I suspect this was originally an accident as the field is a single line and limited by the same amount as commit messages (currently 500 chars), but given the communities now use this feature widely, it appears there is no going back.

K6ka added a subscriber: K6ka.Feb 29 2020, 2:56 PM

It appears that the many users affected by T-Mobile range blocks, which of course will (for the most part) only affect mobile devices, are not able to see any of the helpful templates intended to be viewed in the block notice on mobile, because of this issue.

For example, instead of:
They see:

To nearly all potential editors who view this message, the page and template links are meaningless, the message is meaningless and unclickable, and there's no apparent way to get around the block. This is an extremely pressing bug that should be fixed as soon as possible.

L235 added a subscriber: L235.May 15 2020, 2:58 AM
Niharika triaged this task as Medium priority.Jun 1 2020, 6:51 PM
ARamirez_WMF set the point value for this task to 4.Jun 10 2020, 4:57 PM
dbarratt added a comment.EditedJun 10 2020, 6:30 PM

As @Esanders mentions in T189717#5070532, the bug is a result of an unintentional feature. A possible (but probably unacceptable) solution would be to remove the feature. A more likely solution would be to:

  1. Update the info endpoint (with ApiBlockInfoTrait) to respect the errorformat parameter. T189717#6364215
  2. In MobileFrontend request the blockreason in html format.
  3. If the reason contains any block-level HTML elements then the we know it cannot be displayed in the drawer.
    1. Replace the reason with a "View Reason" link (or popup?) to a new Special Page (perhaps Speical:BlockReason/BLOCKID?) that outputs the reason. This page could also be used for transcluding a block reason somewhere else on wiki.
  4. If the reason only contains inline elements the reason can be displayed in the drawer (we may want to add a way to truncate this and link to the details if it's too long)

A couple of other things from the perspective of the editing team:

  1. This message is shown to a user who has expressed an interest in editing and, for these large range blocks, is likely not a vandal.
  2. We tell the user "Your account has been blocked". This is confusing because they probably don't have an account and aren't signed in. This wording should be changed.
  3. The only call to action is "OK" (aka "Oh well"). After this task is resolved there may also be a "See reasons/details" CTA, but as someone who just wants to edit, there should really be a direct CTA to get around the issue, i.e. "Create an account" (provided account creations aren't blocked as well).

To point (2) we should display messages like:

  • "This IP address has been blocked from editing, but you can still edit by signing in or creating an account."
  • "This IP address has been blocked from editing, but you can still edit by signing in." (if account creation is blocked)
  • For hard IP blocks (where logged in users are still blocked because of their IP address):
    • "This IP address has been blocked from editing, but you may be to edit by signing in." (as they may still be able to edit if their account is exempt)
    • We should also avoid say "you" / "your account" if they are signed in and hard IP blocked.

To point (3) we can then either link the words "signing in" and "creating an account", or provide separate buttons at the bottom of the drawer.

To point (2) we should display messages like: ...

+1, these are great suggestions.

Jdlrobson moved this task from Backlog to team:other on the MobileFrontend board.Jul 24 2020, 3:02 PM
  1. Update the info endpoint (with ApiBlockInfoTrait) to respect the errorformat parameter.

Since T191558 was declined it seems that using the Parse endpoint is more appropriate.

Alternatively, we could limit what can be provided in the block reason as suggested in T191558#4208848. @kaldari do you still think that would be a good idea?

dbarratt updated the task description. (Show Details)Aug 5 2020, 9:00 PM

@dbarratt - My idea would probably be controversial. Parsing the blockreason is probably easier.

dbarratt updated the task description. (Show Details)Aug 6 2020, 2:06 AM

In today's engineering meeting we discussed:

  1. We should keep the drawer
    1. It should show a text version of the reason if its available.
    2. If a text reason is not available we'll show a link to see the full reason. We didn't decide whether the link will take the user to a new page or an expanded version of the drawer
  2. The reason field doesn't always have a reason, for example the template for anonblock.
  3. As @Esanders points out in his comment it is important to tell the user what actions they can take.

The actions that can be taken will depend on the block. Specifically the following properties of the block

  1. Is it an IP only block or a hard IP block (even logged in users would be blocked)
  2. Does the block not allow new users to create an account?
  3. Is it a partial or a full block?
  4. Is the user currently logged out?

We'll have to come up with messaging and actions for all permutations of the above properties.

dbarratt updated the task description. (Show Details)Aug 11 2020, 3:20 PM
ARamirez_WMF removed the point value for this task.
Proc added a subscriber: Proc.Sun, Sep 13, 12:15 PM