@kaldari T152952 was tagged with MW-1.29-release (WMF-deploy-2017-03-28_(1.29.0-wmf.18)), which is what I was going off of. However I just did a quick test on testwiki and sure enough, I see no localStorage entry for the block, but I do see the cookie. Maybe ReleaseTaggerBot was drunk? Anyway I will get a start on formal testing!
So with the localStorage out of the way, it seems testing this is significantly easier. The only *potential* issue I found was the cookie was not restored when attempting to edit from an autoblocked account. So:
- Blocked MusikPuppet
- MusikPuppet logs out, changes IP and logs in as MusikPuppet2
- MusikPuppet2 is autoblocked thanks to the cookie
- MusikPuppet2 deletes cookies
- They still can't edit because the new IP was autoblocked, but the cookie was not restored
Is this intentional? Even if it is not, I don't think it's a big deal, or even a blocker. Once you delete cookies you're past the whole premise of the cookie block.
Sounds like it's basically working, but perhaps not as foolproof as it could be, which is OK. The more "viral" we make it, the more difficult it is for us to keep it from going haywire (and to test). I'm satisfied with this for an initial roll-out.