Page MenuHomePhabricator

Block notices for IP Users on mobile web should use block notice drawer
Closed, ResolvedPublic5 Estimated Story Points

Description

In T165535: Block notices on mobile web for logged-in users provide insufficient information about the block the block notices were fixed for logged in users, but as noted in T165535#4178477 the changes did not apply to IP Users. We should make this change for IP Users.

Links in the block reason will not be parsed until T194566 is completed (i.e. the block reason will be in unparsed wikitext).

Event Timeline

TBolliger moved this task from Untriaged to Triage/To be Estimated on the Anti-Harassment board.
TBolliger added a project: MinervaNeue.

@TBolliger Would the messaging change from:

Your account has been blocked from editing {{SITENAME}}

to

Your IP Address has been blocked from editing {{SITENAME}}

?

TBolliger set the point value for this task to 5.May 9 2018, 7:16 PM

@Jdlrobson The code for this is in MobileFrontend which would prefer:

  1. Move EditorGateway from MobileFrontend to MinervaNeue
  2. Instead of showing a toast notification MobileFrontend would fire an event when an IP is blocked from editing (what would happen if no theme registered an event handler?)
  3. Move the Block Drawer from MinervaNeue to MobileFrontend

Based on MinervaNeue (Desktop), I'm assuming we'd rather do #1, but that seems way out of scope for this task, so that leaves us with #2. What do you think?

  1. is the long term goal, yes.

Personally, I would suggest adding a property/option to the EditorOverlay that is a function that is called when a block in encountered and executed if it has been passed. This would need a change in both MobileFrontend and Minerva.

e.g.

new EditorOverlay( {
  onBlockAction: function () { // do this } 
  ...
} )

Alternatively, yes an event would be fine, provided it is local to the EditorGateway (not a global event using M.on), although I am worrying a little about our use of events in mobile as they make it hard to debug problems.

Ah! Right, I meant EditorOverlay not EditorGateway but passing in a function is a great idea! I'll go with that. Thanks!

Vvjjkkii renamed this task from Block notices for IP Users on mobile web should use block notice drawer to 9odaaaaaaa.Jul 1 2018, 1:12 AM
Vvjjkkii removed dbarratt as the assignee of this task.
Vvjjkkii raised the priority of this task from Medium to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed the point value for this task.
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from 9odaaaaaaa to Block notices for IP Users on mobile web should use block notice drawer.Jul 1 2018, 6:31 PM
CommunityTechBot assigned this task to dbarratt.
CommunityTechBot lowered the priority of this task from High to Medium.
CommunityTechBot set the point value for this task to 5.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.

@Jdlrobson The code for this is in MobileFrontend which would prefer:

  1. Move EditorGateway from MobileFrontend to MinervaNeue
  2. Instead of showing a toast notification MobileFrontend would fire an event when an IP is blocked from editing (what would happen if no theme registered an event handler?)
  3. Move the Block Drawer from MinervaNeue to MobileFrontend

Based on MinervaNeue (Desktop), I'm assuming we'd rather do #1, but that seems way out of scope for this task, so that leaves us with #2. What do you think?

I guess we're actually planning to do the opposite now, to move the mobile editor code from MinervaNeue to MobileFrontend – T198765. I'm starting to work on that and I've just ran into the inconsistent block notifications for logged-in users (implemented in MinervaNeue) and anon users (in MobileFrontend), and I'm glad to find this task. @dbarratt Do you mind if I take over this task and do #3?

Change 444778 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Move fancy block info popups from Minerva to MobileFrontend

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

Change 444779 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/MobileFrontend@master] Move fancy block info popups from Minerva to MobileFrontend

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

@Jdlrobson The code for this is in MobileFrontend which would prefer:

  1. Move EditorGateway from MobileFrontend to MinervaNeue
  2. Instead of showing a toast notification MobileFrontend would fire an event when an IP is blocked from editing (what would happen if no theme registered an event handler?)
  3. Move the Block Drawer from MinervaNeue to MobileFrontend

Based on MinervaNeue (Desktop), I'm assuming we'd rather do #1, but that seems way out of scope for this task, so that leaves us with #2. What do you think?

I guess we're actually planning to do the opposite now, to move the mobile editor code from MinervaNeue to MobileFrontend – T198765. I'm starting to work on that and I've just ran into the inconsistent block notifications for logged-in users (implemented in MinervaNeue) and anon users (in MobileFrontend), and I'm glad to find this task. @dbarratt Do you mind if I take over this task and do #3?

I certainly don't mind as long as @Jdlrobson agrees. I think he preferred #1 or #2.

I ran into some issue on this task because the logged-in and logged-out notice drawers are completely different. The logged-in drawer gets its data delivered from the server on page load, while the logged-out notice gets its data from the API. Ideally this should be standardized (i.e. regardless of the data source, the input/output should be the same). In practice, this means moving some of the logic I have in PHP into JavaScript and normalizing the data that is returned on page load (logged in) to match what the API returns (alternatively, just call the API for both).

Because of this, the task got bigger than I initially expected and unfortunately, fell off of the Anti-Harassment roadmap, but it would be awesome if it was completed as it doesn't look great right now. :( and will look even worse when T2674 is completed.

If we're commited to making this work on all mobile skins then the code should live in mobilefrontend. It sounds like that's the plan now!

I ran into some issue on this task because the logged-in and logged-out notice drawers are completely different. The logged-in drawer gets its data delivered from the server on page load, while the logged-out notice gets its data from the API. Ideally this should be standardized (i.e. regardless of the data source, the input/output should be the same). In practice, this means moving some of the logic I have in PHP into JavaScript and normalizing the data that is returned on page load (logged in) to match what the API returns (alternatively, just call the API for both).

Yes, I am changing them both to call the API.

Thank you for taking this on!

In the long-long run we'll need to solve how template-based block reasons display (T189717). We've skipped this for now because it may require some significant changes to how blocks are set.

Change 444779 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add fancy block info popups from Minerva to MobileFrontend

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

Change 444778 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Remove fancy block info popups (move to MobileFrontend)

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