@MusikAnimal: This isn't actually assigned to anyone (although it's in In Development). Are you taking it?

@kaldari Sure! We need to wait till Tuesday though, right?

@MusikAnimal: Yeah, last Tuesday :)

Code was merged on the 20th and got deployed to Test Wikipedia on the 21st.

@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.

The same is true without changing IPs:

• Blocked MusikPuppet
• MusikPuppet logs out, deletes cookies, logs in as MusikPuppet2
• They are autoblocked, but the cookie isn't restored