Page MenuHomePhabricator

VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show <Blockedtext> with log entry
Closed, ResolvedPublic

Description

When a blocked users attempts to edit a page in the classic editor they see a large, red-bordered notice that tells them:
*They are unable to edit, but they can still read
*Who blocked them
*Why they are blocked (shows them the block log extract)
*When the block expires
*That they can usually edit their talk page and email other editors and aministrators
*What to do if the block is unclear or doesn't seem relevant
*How to appeal a block (links to policy and guide)
*That they can view and copy the source of a page

In contrast when a blocked user attempts to edit a page in VE
*No notice appears, and editing works as normal
*When they click "Save page" they can review their changes and enter an edit summary as normal

When they try to save their edits they see a small white box with a message that tells them:
*There was a server problem
*Their request was unsuccessful because they have been blocked
They can then choose only "OK" which takes them back to the save page dialog.

This is very bad because
*The message they see appears to say they caused a server error - cue panic mode for non-technical users ("Help! I've broken Wikipedia!" - that is exactly the reaction I would expect from my mother.)
*They have wasted potentially lots of time on an edit they cannot save
*It doesn't tell them what being blocked means
*It doesn't tell them who blocked them or for what reason
*It doesn't tell them what they can do to get help - they can't ask questions at the page that seems to be about asking questions for example (see Bug 51875)
*It doesn't tell them when the block expires, how they can appeal it or how they can contact anybody.

For some users it is even worse that that - saving fails silently: Bug 51999


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51999
https://bugzilla.wikimedia.org/show_bug.cgi?id=51454
https://bugzilla.wikimedia.org/show_bug.cgi?id=51547
https://bugzilla.wikimedia.org/show_bug.cgi?id=53009

Details

Reference
bz52004

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:44 AM
bzimport set Reference to bz52004.

Created attachment 12953
What a blocked user sees when they try to save an edit in VE

Attached:

blocked_in_VE.png (343×1 px, 101 KB)

Created attachment 12954
What a blocked user sees immediately they the source editor loads

Attached:

blocked_in_Source.png (527×1 px, 77 KB)

James suggested I tackle this bug. I messed around with the API for a little bit and assuming I didn't miss anything:

I think that if we tried to fill out the 'blockedtext' message properly on the client we'd have to:

  • Query the API for the user's blockinfo to determine whether or not they're blocked. If they are:
    • Query the API for more info about this block which meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute into the message (expiry, user, timestamp).
    • Query the API to parse the blockedtext message because it can't be done on the client (even the default message includes stuff mw.msg can't handle)
    • Substitute the data we have into the message (and we still won't have $3 - the current IP)
      • Mess around with dates/times because they won't be in the right format.

Another way we could do this is return the full warning from action=visualeditor&paction=parse (therefore adding no extra API requests) which would cause the client to stop loading. I don't like this idea because obviously that paction is not intended for checking this kind of thing...

Or we could ignore the core blockedtext message and use our own "Your username or IP address has been blocked", possibly with the info that just meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).

Or we could add a new API module/paction that can be queried once and provides all the relevant info. I don't like this idea either but it seems the nicest.

Thoughts?

(In reply to Alex Monk from comment #3)

James suggested I tackle this bug. I messed around with the API for a little
bit and assuming I didn't miss anything:

I think that if we tried to fill out the 'blockedtext' message properly on
the client we'd have to:

  • Query the API for the user's blockinfo to determine whether or not they're

blocked. If they are:

  • Query the API for more info about this block which

meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute
into the message (expiry, user, timestamp).

  • Query the API to parse the blockedtext message because it can't be done

on the client (even the default message includes stuff mw.msg can't handle)

    • Substitute the data we have into the message (and we still won't have $3
  • the current IP)
    • Mess around with dates/times because they won't be in the right format.

Another way we could do this is return the full warning from
action=visualeditor&paction=parse (therefore adding no extra API requests)
which would cause the client to stop loading. I don't like this idea because
obviously that paction is not intended for checking this kind of thing...

Or we could ignore the core blockedtext message and use our own "Your
username or IP address has been blocked", possibly with the info that just
meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).

Or we could add a new API module/paction that can be queried once and
provides all the relevant info. I don't like this idea either but it seems
the nicest.

We already put random junk in the paction=parse response, I wouldn't be opposed to adding blocked-ness to that. Another paction would be OK too, but then we'd have to make two API requests.

There are significant speed benefits in combining everything into one API request. I think we should stop kidding ourselves that paction=parse is a clean, only-does-one-thing action, and perhaps rename it if we want, rather than trying to split it into separate actions, because the latter would just make client-side performance worse.

(In reply to Roan Kattouw from comment #4)

We already put random junk in the paction=parse response, I wouldn't be
opposed to adding blocked-ness to that. Another paction would be OK too, but
then we'd have to make two API requests.

There are significant speed benefits in combining everything into one API
request. I think we should stop kidding ourselves that paction=parse is a
clean, only-does-one-thing action, and perhaps rename it if we want, rather
than trying to split it into separate actions, because the latter would just
make client-side performance worse.

Yes, since writing that comment I decided to just add it in to paction=parse, especially since talking to James - he wants this to be an edit notice like the others. I probably should have left a new comment about it.

The problem now is coming up with a nice way to fit the autoblockedtext message (blockedtext is okay) in to the edit notices popup.

Change 119204 had a related patch set uploaded by Alex Monk:
Show blockedtext message in edit notices

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

Change 119204 merged by jenkins-bot:
Show blockedtext message in edit notices

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