This definitely doesn't seem to be fixed:

In T150419#3232595, @Mooeypoo wrote:

Just an idea here -- if we want to make this private (and I agree we should) then how about adding a new preference for this?

Ideally, this would include a proper user lookup mechanism with fancy API requests and an "add/remove" functionality, but that would require more work. As an "MVP" (Minimal Viable Product) solution we can start by having a super-minimal interface for this preference - a textbox, where users can type in the usernames that they want to block.

The only issue technically is to make sure that the separators in that textbox are things that are illegal to use in a username. Comma doesn't work (it's legal to have a comma in a username) but either pipe (|) or new lines work. I usually dislike the idea of having users type in pipe to separate stuff, because it's super unintuitive, so if the preferences system supports multiline textboxes, then having a username per line (with \n as separators) is best, but I am not sure we have that in preferences, so if that isn't available, we can just start with a basic input and tell users they can add the users with a pipe.

And if this works out, we can later improve this interface -- maybe even if a fancier OOUI lookup element that actually searches and finds the username for you. It could even be a nice Google CI task, or an Outreachy/GSoC/RGSoC microtask.

Do we really need that much gradation? It seems like it would still work with a few "bins" for color coding, which could be set to actual standard colors.

In T131492#2923360, @Phantom42 wrote:

Implementation

Here goes the tricky part. And we have some different options on how to do that too.

1. We can create new HTMLForm field, extending HTMLTextField (using HTMLUserTextField as example). We also create new InputWidget and js + css module related to it: we can use the copy of mw.widgets.UserInputWidget as starting point and then try to extend its functionality. To implement the first variant of design, we will need just to add some html of the list before the input and insert new element to it each time new username is entered. To implement the second variant, we can add div before the input, containing the list of users. Some hacks will be needed to make it work: I think we will need to set div position to absolute to make it overlay the input and we need to modify inputs padding to shift the position, where the new text is entered.

2. We can create new HTMLForm field, extending HTMLFormField. Some js + css modules will also be needed. We will create new input from scratch, trying to make it match the design of other inputs using css. That will be a bit more simple, and we will use less hacks to make it work. And I think it will work better. However, there is one disadvantage: looks like it will not use OOui at all, so some work will be needed to make it look like other inputs.

3. Maybe try to create completly new OOui widget.

Even stranger:

It's a Monobook versus Vector issue. Kghbln is using Monobook, Deskana is using Vector.

Yes, but I still have no reliable way to reproduce it. About the only thing I can say is that it seems to spike after Phabricator updates and then die down over time, though that may just be a coincidence or just my perception.

I don't see scrollbars on FF 48.0.1 on Mac.