If you are logged in as a blocked user on a new IP and attempt to edit from the mobile version of a site (without the VisualEditor extension), this also does not cause the new IP address to be blocked. I don't know if I should raise this as a separate bug for MobileFrontend, or whether both bugs have the same root causes.

VisualEditor and MobileFrontend both use the action=edit API for saving changes.

Change 491300 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] API: Spread autoblocks from action=edit and action=move

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

Change 491300 merged by jenkins-bot:
[mediawiki/core@master] API: Spread autoblocks from action=edit and action=move

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

The fix should be deployed to Wikimedia wikis with 1.33.0-wmf.19 or later.

This seems resolved as far as I'm concerned. I'll leave it to the VE team to close it since I know they like to do additional verification first.

Thank you for fixing this!

We mostly use our "additional verification" process for things somebody on the team worked on (and that are tagged with VisualEditor (Current work)). I was going to just close this task, but on second thought, this could probably use proper QA verification. Especially since VisualEditor uses a wrapper around the action=edit API.

I think we are done with this ticket. Tag us again if there are problems.

@dom_walden is T196575 a duplicate of this task or a different issue?

In T216245#5206222, @dbarratt wrote:

@dom_walden is T196575 a duplicate of this task or a different issue?

I don't know. I assume setting cookies and spreading autoblocks are different, and it is possible to do one and not the other.

@dom_walden: Is it working for you now? :)

In T216245#5368871, @Ryasmeen wrote:

@dom_walden: Is it working for you now? :)

Thanks!

I see the autoblock being spread when I do the move and edit actions via the API (api.php?action=move and api.php?action=edit).

However, I don't see it spread when I attempt to edit a page with the VisualEditor while blocked, in the same way I do when attempting to edit a page with the source editor while blocked.

Presumably because simply clicking "Edit" on the page and loading the VisualEditor does not call action=edit.

I don't know if we want VisualEditor to mirror what the source editor does, and aggressively spread an autoblock as soon as a user attempts to edit a page.

In T216245#5371018, @dom_walden wrote:

Presumably because simply clicking "Edit" on the page and loading the VisualEditor does not call action=edit.

I don't know if we want VisualEditor to mirror what the source editor does, and aggressively spread an autoblock as soon as a user attempts to edit a page.

When you click "Edit" your browser makes two HTTP requests:
https://example.com/api.php?action=visualeditor&format=json&paction=metadata&page=Test&uselang=en&formatversion=2
and
https://example.com/api/rest_v1/page/html/Test?redirect=false&stash=true

I'm not sure if the first is cached or uncached. If it's uncached, then it should spread the autoblock. If it is cached, then it is like the request to "Read" and it should not spread the autoblock.
The second is to the RESTBase web service, which is unaware of the user (afaik).

Visual editor does make some other POST requests before publishing to cache the changes on the server. Since those are POST requests they could spread the autoblock. Otherwise it wont be spread until the actual publish takes place.

So the original patch in February made it so that VE (and mobile wikitext editor) would spread autoblocks when you tried saving your changes, but not when you opened the editor. Since then, we've improved our permission checks and now if you're blocked, you don't get an option to save (like the "view source" mode in old wikitext), so there's no way for the spreading to happen.

I am not sure what is actually the expected behavior. Should autoblocks even be spread when opening the editor? If so, we might need a separate API action for doing that… (in VE we can add that code to action=visualeditor, but this doesn't fix the issue for mobile wikitext editor). Or maybe action=query&prop=revisions should also spread autoblocks?

Hmm, I suppose this is more of a product decision for @Niharika

I am not sure what is actually the expected behavior. Should autoblocks even be spread when opening the editor? If so, we might need a separate API action for doing that… (in VE we can add that code to action=visualeditor, but this doesn't fix the issue for mobile wikitext editor). Or maybe action=query&prop=revisions should also spread autoblocks?

What's the case for the classic editors at the moment? I think that they don't spread the block when the editor is opened, is that correct?

In T216245#5387071, @Niharika wrote:

I am not sure what is actually the expected behavior. Should autoblocks even be spread when opening the editor? If so, we might need a separate API action for doing that… (in VE we can add that code to action=visualeditor, but this doesn't fix the issue for mobile wikitext editor). Or maybe action=query&prop=revisions should also spread autoblocks?

What's the case for the classic editors at the moment? I think that they don't spread the block when the editor is opened, is that correct?

From experimenting, they do spread it as soon as it is opened.

Thanks @dom_walden for checking!
I am not entirely sure why the decision was made to spread the block as soon as the source editor is opened. If someone has context behind that, I'd like to look into it. It seems a little too aggressive to me.
Nevertheless, it makes sense for both the standard editors and VE to have the same behavior. I think it is Peter's call to say whether it is worth investing time in changing VE to match the behavior of the standard editors.

Looks like it probably copies the spreading of auto-blocks. That dates back to http://mediawiki.org/wiki/Special:Code/MediaWiki/99323; before that autoblocks were spread on every block check, and before that on every request.

@ppelberg it is your call to determine if this is high priority or should go in the freezer

The Editing team does not have a capacity to work on this task at this time.