Change 320332 had a related patch set uploaded (by Mooeypoo):
[super-atomic-WIP] Adding filters to RecentChanges

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

@Pginer-WMF Just one thing (most likely already discussed)

• Is the contrast between the magnifying glass icon and grey text "Filter recent changes (browse or start typing)" is a little too much? The wiki general search box above has less contrast.
• The magnifying glass icon is not functional (the same icon in the general search box is actually a 'searchButton' ); it makes sense to make it less prominent.

In T149435#2807550, @Etonkovidova wrote:

@Pginer-WMF Just one thing (most likely already discussed)

Thanks for the input, @Etonkovidova. I don't think we went into discussing these specific details before.

• Is the contrast between the magnifying glass icon and grey text "Filter recent changes (browse or start typing)" is a little too much? The wiki general search box above has less contrast.

Here we are just using a standard component: an input field with icon and placeholder text. The grey text is the usual input field placeholder. It is shown in a lighter grey when the input field is empty, but the text that users write will be shown in the usual darker text color. M82 includes more details on colors and their use for placeholders (#72777d) and regular text (#222).

• The magnifying glass icon is not functional (the same icon in the general search box is actually a 'searchButton' ); it makes sense to make it less prominent.

The magnifying glass icon still works as an entry point for the text field. During testing it was not unusual that users clicked on the icon to get into the text field. It also serves as an anchor for the main entry points of filters. I'm not sure if we have a standard recommendation for icons on input fields (@Volker_E?). It seems that many OOUI forms use icons in pure black with an even higher contrast, which seems too much in many cases.

Thanks for bringing this up. There is currently an inconsistency between two similar types of input fields in our interfaces from my perspective – similar in iconography:

• • Type indicator icon: Let's stay with a search bar like input here, the search icon works as indicator and label (I think that's what you've meant with “entry point” @Pginer-WMF, right?) A form input label resulting on focussing the input field and activating the text input cursor when clicked. The proposed interface above features this kind.
• Type form action icon: Where clicking the search icon results in a form server request. In an LTR interface the icon is most often placed on the right end of the input form. Vector currently features this type, Wikipedia Portal features a similar one.

I would pledge to indicate an action element much stronger than it's currently done in the Vector interface. IMHO a (primary or normal) button element similar to the one in SelectFileWidget would be a UX improvement. There are plans to change the Vector search box over to OOjs UI (I can't find the patch right now).
The indicators could then be remain as is (following the text color close-by).

In T149435#2812962, @Volker_E wrote:

I would pledge to indicate an action element much stronger than it's currently done in the Vector interface. IMHO a (primary or normal) button element similar to the one in SelectFileWidget would be a UX improvement. There are plans to change the Vector search box over to OOjs UI (I can't find the patch right now).
The indicators could then be remain as is (following the text color close-by).

From inspecting the demo, it seems the SelectFileWidget is using a tag icon in pure black (#000) color, I'd expect it to be at text color (#222) as the darkest. Icons on buttons in the demo seem to use a lighter grey compared to pure black. I think the later works better in conjunction with text.

(If this requires further discussion, it may be better to create a separate ticket)

@Pginer-WMF This is a good point.
The indicators in ButtonWidgets for example got changed to follow the text color #222 with opacity 0.87.
From current perspective the reason for pure black text (and with it black icons) in the input fields is, that we want to emphasize user inputs. M101 also features black text on inputs. We could do this just on :focus or weigh in on the options (and putting an icon set to lower opacity besides black text is none of them):

• Leave inputs at #000 and also leave icons as is
• Put input icons and text to #222 or
• Put input icons and text to #222 and change to black when focussed or (and that might technically be possible too)
• Put input icons to #222 and change them to black when inputs are filled (it wouldn't be a difference if inputs are pre-filled, they would be black, also take account that placeholder text with icons is never the same color).

In T149435#2823960, @Volker_E wrote:

@Pginer-WMF This is a good point.
From current perspective the reason for pure black text (and with it black icons) in the input fields is, that we want to emphasize user inputs.

I agree in having text inputs visible, but the question is how much to emphasise them over other similar elements (is a free-text input always more important than a drop-down based input next to it?).

I'd prefer emphasis to be applied on less elements at a time to make it more effective. I'd prefer using #222 by default without further distinctions on the type of input. We can experiment to use the option to go darker to #000 on one element at a time (e.g., when hover/focus). As shown in this codepen, the change even on hover is more of a subtle change to increase contrast than something to emphasise one type of elements over others.

Change 325851 had a related patch set uploaded (by Mooeypoo):
Add userExpLevel filter in the RCFilters UI

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

Change 320332 merged by jenkins-bot:
Adding new interface for review filters to RecentChanges

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

Change 325851 merged by jenkins-bot:
Add userExpLevel filter in the RCFilters UI

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

For QA -- The operation of the drop down is complete, but not all filters are implemented yet (they are coming up in incremental commits) Take that into account when testing.

I marked as minor the issues that I think are minor. @Pginer-WMF (and maybe @jmatazzoni) please take a look to decide if the issues are worth to be addressed.

(1) (minor - could be a non-issue) If a user double-click in the search field, the field will be outlined, indicating that the focus is on it. Start typing, e.g. 'Bot', no suggestions of filters are displays. You need to click somewhere else to make searching for filters work again.
So, the following screenshot illustrates the case - the Search field is outlined, and the cursor is in it, but suggestions are not displayed.

(2)

When the Search Bar gets the focus, the page scrolls so that the Active Filter Display Area moves to the top of the viewport

I did not see that happening; it could be just limitations of the present placement of 'Active filters' on the RC page?

(3)

The search looks first for menu items that start with the query text; if there are no results, it falls back to match filters containing the query string anywhere in their name or description.

vs

Search considers the filter names only (i.e., it does not look at the description texts).

The match will be found only in the filter names, not in descriptions or filter group names.
e.g. '10 edits' will not find anything; 'edits' will be match with filter names containing that string in their names.

(4)

When search finds matches, the first result is highlighted in blue. Pressing enter will select that filter (or unselect it if it is already selected). Up and down arrows will allow to select a different filter from the list of matches.

Not implemented yet?

(5) No trash bin icon

(6) The redundant filters selection, e.g. 'Newcomers', 'Experienced users', 'Registered', and 'Unregistered' (selected in any order), will be silently reduced to 'Newcomers' and 'Experienced users'.
The filters that will display all records - e.g. 'Newcomers', 'Learners', Experienced users', 'Registered', and 'Unregistered' - will disappear from the Search box upon clicking on 'Show' without giving any feedback to a user that all entries are shown.

(7) (minor) the Search icon looks bigger than it was specified.

oo-ui-textInputWidget.oo-ui-iconElement .oo-ui-iconElement-icon {
    max-height: 2.5em;
    left: 0.46875em;

(8) (minor) 'No filters found' looks different from the spec screenshot:
'Filters' label is not bolded; 'No filters found' - a different color for the font.

.mw-rcfilters-ui-filtersListWidget-noresults {
    padding: 0.5em;
    color: #666;

(9) Adding one filter 'Registered' to the RC page with default selection, will produce the following url:
https://en.wikipedia.beta.wmflabs.org/w/index.php?namespace=&tagfilter=&hidebots=0&hideliu=0&title=Special%3ARecentChanges&hideanon=1&userExpLevel=all&hidemyself=0&hidebyothers=0&hidehumans=0&hideminor=0&hidemajor=0&hidepageedits=0&hidenewpages=0&hidecategorization=0&hidelog=0

Is it expected? I'd think that 'Registered' filter will display only edits done by registered users, not changes in Categories or Log entires.

Selecting only 'Unregistered' filter will not display Logged entires, although hidelog=0:
https://en.wikipedia.beta.wmflabs.org/w/index.php?namespace=&tagfilter=&hidebots=0&title=Special%3ARecentChanges&hideliu=1&hideanon=0&userExpLevel=all&hidemyself=0&hidebyothers=0&hidehumans=0&hideminor=0&hidemajor=0&hidepageedits=0&hidenewpages=0&hidecategorization=0&hidelog=0

@Mooeypoo - please take a look at possible issues in RTL. If those are, in fact, issues, let me know and I'll file a separate ticket(s).

(1) the drop-down is displayed on the left.

(2) The vertical alignment of the filter label text and X is a little bit off? The text looks not vertically centered.

In T149435#2963504, @Etonkovidova wrote:

I marked as minor the issues that I think are minor. @Pginer-WMF (and maybe @jmatazzoni) please take a look to decide if the issues are worth to be addressed.

(1) (minor - could be a non-issue) If a user double-click in the search field, the field will be outlined, indicating that the focus is on it. Start typing, e.g. 'Bot', no suggestions of filters are displays. You need to click somewhere else to make searching for filters work again.
So, the following screenshot illustrates the case - the Search field is outlined, and the cursor is in it, but suggestions are not displayed.

We seem to have an issue here with the popup ironically ignoring $autoCloseIgnore, so clicking on the input twice seems to close the popup?
We should look into that.

(2)

When the Search Bar gets the focus, the page scrolls so that the Active Filter Display Area moves to the top of the viewport

I did not see that happening; it could be just limitations of the present placement of 'Active filters' on the RC page?

Not implemented. Good catch.

(3)

The search looks first for menu items that start with the query text; if there are no results, it falls back to match filters containing the query string anywhere in their name or description.

vs

Search considers the filter names only (i.e., it does not look at the description texts).

The match will be found only in the filter names, not in descriptions or filter group names.
e.g. '10 edits' will not find anything; 'edits' will be match with filter names containing that string in their names.

That's right. It only searches in filter names for the moment. We can fix that.

(4)

When search finds matches, the first result is highlighted in blue. Pressing enter will select that filter (or unselect it if it is already selected). Up and down arrows will allow to select a different filter from the list of matches.

Not implemented yet?

No; highlight of the filter wasn't implemented (good catch) and arrows are a different issue altogether. Tab should work, but we should implement behavior for arrow keys specifically. This might be a longer task, might deserve its own ticket.

(5) No trash bin icon

The behavior of clearing filters and setting to defaults is implemented in a patch that's waiting to be merged.

(6) The redundant filters selection, e.g. 'Newcomers', 'Experienced users', 'Registered', and 'Unregistered' (selected in any order), will be silently reduced to 'Newcomers' and 'Experienced users'.
The filters that will display all records - e.g. 'Newcomers', 'Learners', Experienced users', 'Registered', and 'Unregistered' - will disappear from the Search box upon clicking on 'Show' without giving any feedback to a user that all entries are shown.

Sorry, I don't understand the problem? If you selected all filters in the group, then it is practically and virtually equivalent to selecting none (because filters are flipped from the parameters, negative and positive) -- so when you hit "show" it will give you the corrected view, which is none is selected. This is also by spec.
Is this not what is happening?

(7) (minor) the Search icon looks bigger than it was specified.

oo-ui-textInputWidget.oo-ui-iconElement .oo-ui-iconElement-icon {
    max-height: 2.5em;
    left: 0.46875em;

The icon is ooui icon inside an ooui textbox. I can make it smaller, but we should see if @Pginer-WMF wants to specifically make it smaller than the system default (of OOjs-UI) or leave as-is. I have no preference, it's a CSS issue we can fix fairly quickly, but I am not sure if it was intentionally smaller or not?

(8) (minor) 'No filters found' looks different from the spec screenshot:
'Filters' label is not bolded; 'No filters found' - a different color for the font.

Yeah I started a task about fixing the colors for all the UI here based on the MW color scheme, and with less mixins. Hopefully it will fix this too.
See T156164: RCFilters UI: Use mixins and variables in Less files

(9) Adding one filter 'Registered' to the RC page with default selection, will produce the following url:
https://en.wikipedia.beta.wmflabs.org/w/index.php?namespace=&tagfilter=&hidebots=0&hideliu=0&title=Special%3ARecentChanges&hideanon=1&userExpLevel=all&hidemyself=0&hidebyothers=0&hidehumans=0&hideminor=0&hidemajor=0&hidepageedits=0&hidenewpages=0&hidecategorization=0&hidelog=0

Is it expected? I'd think that 'Registered' filter will display only edits done by registered users, not changes in Categories or Log entires.

Yes. For the moment, the URL is updated with all filter statuses. There's a code comment that suggests we re-evaluate this in the future, but this also means that if you share this specific URL, then whoever loads it will get exactly the same result regardless of their default preferences (because all filters are defined). We can decide to change it, but it will mean people may see different results for the same URL, so we need to decide if that's what we want vs. long URLs.

Selecting only 'Unregistered' filter will not display Logged entires, although hidelog=0:
https://en.wikipedia.beta.wmflabs.org/w/index.php?namespace=&tagfilter=&hidebots=0&title=Special%3ARecentChanges&hideliu=1&hideanon=0&userExpLevel=all&hidemyself=0&hidebyothers=0&hidehumans=0&hideminor=0&hidemajor=0&hidepageedits=0&hidenewpages=0&hidecategorization=0&hidelog=0

Hm, not sure about this one. @Mattflaschen-WMF @SBisson might be able to assist? The combination of the log results with other filters confuses me a bit, I'm nto sure I understand the current constraints in the backend.

In T149435#2963613, @Etonkovidova wrote:

@Mooeypoo - please take a look at possible issues in RTL. If those are, in fact, issues, let me know and I'll file a separate ticket(s).

(1) the drop-down is displayed on the left.

Known bug, annoyingly.

Basically, inputs in the content section of MediaWiki are considered "content direction" -- and for the most part they are. In this case, however, we have an input that is supposed to be interface direction. We just need to get the JavaScript instance of the input in the FilterCapsuleMultiselectWidget to have dir="" value that is

$( body ).css( 'direction' );

(which is the interface dir)

@Catrope you mentioned you were looking into this?

(2) The vertical alignment of the filter label text and X is a little bit off? The text looks not vertically centered.

Hm, not sure about that one. Worth a look, might also be about mixed up ltr/rtl definitions.

In T149435#2967408, @Mooeypoo wrote:

No; highlight of the filter wasn't implemented (good catch) and arrows are a different issue altogether. Tab should work, but we should implement behavior for arrow keys specifically. This might be a longer task, might deserve its own ticket.

I don't think we'd have to implement arrow key behavior ourselves; it's built-in behavior in OOUI menus. I know there's some weirdness in our usage of it, but we should try to use MenuWidget's arrow key and selection/highlight functionality rather than reimplement all of that stuff.

(6) The redundant filters selection, e.g. 'Newcomers', 'Experienced users', 'Registered', and 'Unregistered' (selected in any order), will be silently reduced to 'Newcomers' and 'Experienced users'.
The filters that will display all records - e.g. 'Newcomers', 'Learners', Experienced users', 'Registered', and 'Unregistered' - will disappear from the Search box upon clicking on 'Show' without giving any feedback to a user that all entries are shown.

Sorry, I don't understand the problem? If you selected all filters in the group, then it is practically and virtually equivalent to selecting none (because filters are flipped from the parameters, negative and positive) -- so when you hit "show" it will give you the corrected view, which is none is selected. This is also by spec.
Is this not what is happening?

Note that there's also a patch waiting to be merged that grays out inactive filters.

Selecting only 'Unregistered' filter will not display Logged entires, although hidelog=0:
https://en.wikipedia.beta.wmflabs.org/w/index.php?namespace=&tagfilter=&hidebots=0&title=Special%3ARecentChanges&hideliu=1&hideanon=0&userExpLevel=all&hidemyself=0&hidebyothers=0&hidehumans=0&hideminor=0&hidemajor=0&hidepageedits=0&hidenewpages=0&hidecategorization=0&hidelog=0

Hm, not sure about this one. @Mattflaschen-WMF @SBisson might be able to assist? The combination of the log results with other filters confuses me a bit, I'm nto sure I understand the current constraints in the backend.

Many wikis are set up in a way so that unregistered users cannot cause log entries to be created, because you need special rights to do things that cause log entries. However, wikis can be set up to, say, allow unregistered users to move pages, which would create log entries. But I don't think there's anything that an unregistered user can do on enwiki that would create a log entry.

In T149435#2967430, @Mooeypoo wrote:

@Catrope you mentioned you were looking into this?

Yeah I have new ideas about fixing the RTL behavior of the popup, so I'll poke at that again.

(2) The vertical alignment of the filter label text and X is a little bit off? The text looks not vertically centered.

Hm, not sure about that one. Worth a look, might also be about mixed up ltr/rtl definitions.

That does look wrong but it would also be a bug in OOUI, not our code. (We should still fix it, but just saying.)

Thx @Mooeypoo and @Catrope. I'll keep my comments as tests for future/regression testing.

The summary
(1) Filed as a separate issue T156214: RC search filter bar double click - suggestions are not displayed

(2) and (5) - Will wait for implementing functionality

(3) Filed as a separate ticket T156215: RC - filters group names and descriptions should be searchable

(4) re-check later

(6) Simply, I do not like the idea of dismissing user input (the selected filters) without providing a clear feedback why it was done. I do not think that the following would be clear to users.

If you selected all filters in the group, then it is practically and virtually equivalent to selecting none

When I see the filters that I selected disappear, the first guess would be that something is not working right. But I agree with @Catrope - to wait for implementation of greyed out filters.

(7) Will follow up with @Pginer-WMF - also it should be to helpful to go through all visual specs for the Filter Search bar

(8) Already the ticket is filed: (8) T156164: RCFilters UI: Use mixins and variables in Less files

(9) Yes, it could be some temporary state. Will follow up @SBisson and @Mattflaschen-WMF .

(7) (minor) the Search icon looks bigger than it was specified.

The magnifying glass should be the same size as the text. In the designs I used 16px, currently it is bigger.
Note that I'm referring to the size of the shape, if the visual asset has additional margin around the shape that needs to be added to the calculation.

Note the magnifying glass icon at the bottom of the layout reference below (as well as the spacing between the icon and the text):
T149435

I highlighted the icon area below with a 16px square reference (images are exported at 2x for ease of visualisation):

Current	Expected (prototype screenshot)

When selecting filters from a group that result in all results being displayed, they should be shown as active in the list, since the results they represent are present in the list. This is not happening right now. If I select "registered" and "unregistered", I'd expect the filters in the list to look enabled, while the tags in the filter area to be greyed out.

The comparison below shows the current behaviour compared to the expected one (reflected in the prototype):

Current	Reference

@Pginer-WMF your last comment was filed as T156429: RC - Selecting all filters in a group makes them grey out

In T149435#2974404, @Etonkovidova wrote:

@Pginer-WMF your last comment was filed as T156429: RC - Selecting all filters in a group makes them grey out

Doesn't this go against the specs? I'm confused.

The way things work right now is the following (and I am ignoring highlighting for now ):

Filters are positive, which means that what is selected is what you filter for, but if an entire group is unselected, you see it all. This is the reason why if you choose all elements of a group, it is as if you selected no element of the group - the view you get in the result is the same.

So if you have a group, say, "User experience", and you chose "Newcomer", the rest of the filters in the same group are now not active anymore (unlike before you selected anything, because before, nothing was selected from the group, so you saw them all) -- which means the rest of the items turn grey, to indicate to you that you do not actually see them anymore.

On top of that, we have explicit exclusion behavior, where certain filters, when we select them, are essentially excluding other filters (there's a list of those in the parent spec)

As far as I understand the issue (and please @Pginer-WMF, your input here) --

What we need to fix is the case where all filters of this group are selected (as opposed to "some of them") where if that's the case, it's the same as if none are selected, which means they are no longer excluding one another -- and should actually all be active.

However, if we have groups with more than 2 filters, and only some filters are selected in that group, then whatever is not selected, should be "inactive" (greyed out).

Is this the case we should fix?

I think one of the key confusion points to fix here is the issue where selecting everything in the same group is equivalen to selecting none in the same group

If we agree that the "active state" (the greyed-out state both in the filter list and the filter 'bubbles' at the top) shows you filters that don't really affect your query, then selecting all filters of a group is that state -- if you select them all, it's as if you selected none, and the next time you click "show" (or repaste the relevant URL) the UI will display the 'no filters selected in this group' because that's the actual state of your query.

This is confusing on its own, but I thought that the active state of the filters actually makes it easier on the user to understand, because the greyed out parts would also be parts that will not appear as selected the next time you click "show" or refresh the same generated URL.

Does this make sense?

@Mooeypoo writes:

What we need to fix is the case where all filters of this group are selected...which means they are no longer excluding one another -- and should actually all be active.

In the prototype, I notice that when all filters in a group are selected, none of them is grayed out. That's in the Dropdown Panel—the Active Filter Display Area has different rules.

That behavior is covered, I think—though somewhat obliquely— in the The Dropdown Filter Panel spec (T149452), where it says:

Note that the excluded filters can still be selected, which will change their display state to active...

In T149435#2974684, @jmatazzoni wrote:

@Mooeypoo writes:

What we need to fix is the case where all filters of this group are selected...which means they are no longer excluding one another -- and should actually all be active.

In the prototype, I notice that when all filters in a group are selected, none of them is grayed out. That's in the Dropdown Panel—the Active Filter Display Area has different rules.

Okay, so it seems like the *only* thing we should fix here is that when all elements of the group are selected, they're all active.

I can do that, but I fear this will then be confusing to see that when you refresh this page, none of those filters appear anymore, because we are normalizing the query. It seems like the wrong indication to me; they are greyed out because they're essentially not active because they're all active.

... this is super confusing, but it's an important point.

That behavior is covered, I think—though somewhat obliquely— in the The Dropdown Filter Panel spec (T149452), where it says:

Note that the excluded filters can still be selected, which will change their display state to active...

Yeah, I have to say, that this is not helping making things clearer. I will change the behavior of the items when the entire group is selected and I think that will fix this issue.

@Mooeypoo wrote:

I can do that, but I fear this will then be confusing to see that when you refresh this page, none of those filters appear anymore, because we are normalizing the query.

Yeah, @Etonkovidova showed me that normalizing behavior today on the beta site. I don't think visibly removing the user's settings is a good idea. (For @Pginer-WMF or anyone else who haven't seen this: go to the beta page, select both the Registered and Unregistered filters, then click Show. The filter settings disappear.)

Firstly, as it is now it's a pretty jarring user experience. I understand why you're doing what you're doing. But to the user, I'm pretty sure it will look like the page just lost his settings. Most likely he'll just put them back in.

Secondly, I don't know how that normalizing behavior would work once we get rid of the need to press Show. I mean, what, you'd have to make it so that when the user selected the last filter in a group, the others would toggle to unselected. I don't think we want to go there. @Pginer-WMF please weigh in.

IMHO, for most of the "exclusion" states as you're calling them, there's no real effect on the user, meaning the user gets what he asked for. To educate the user about how the filters work, we've defined a number of cues in T149391. The cues are subtle, and many users will miss them, but since the user is suffering no harm, that really doesn't matter. There are a few states—the "Conflict" states— that do harm the user, and I just proposed a new, more forceful way to inform the user about these in T156427.

I want to point out that this behavior will not be as jarring once we have the AJAX ("load as you click the filters") behavior -- which is coming very VERY soon. The point of the normalization is to make it consistent between instances and users who may share states (by URL or whatever else)

If the normalization happens only once (when you load the page, or reload a previously saved state) it is a lot less of an issue (and more of a POSITIVE correction) than what we see right now with using the "show" button.

But the "show" button is temporary; the actual behavior would be loading the results immediately in the background without changing what the UI shows you so if you chose 3 items inside a group of 3, they will still be shown as you see the results. they will only vanish if you reload this state again later (to "normalize" the query) or if you give the URL to someone else, who loads it on top of their different defaults, so that they can see exactly what you see.

Does this make sense? Can we postpone judgment on how to fix htis (and how jarring it is to the user) until the AJAX request is working?

I think we might actually change our minds here when we see it in action similar to the prototype.

In T149435#2974623, @Mooeypoo wrote:

What we need to fix is the case where all filters of this group are selected (as opposed to "some of them") where if that's the case, it's the same as if none are selected, which means they are no longer excluding one another -- and should actually all be active.

However, if we have groups with more than 2 filters, and only some filters are selected in that group, then whatever is not selected, should be "inactive" (greyed out).

Is this the case we should fix?

Yes. This is exactly the case to be fixed. The ticket created (T156429) may have a confusing title, feel free to adjust the title and description to make that more clear.

This is a test case based on the prototype showing the different situations:

No filters in a group	Some filters in a group	All filters in a group
No tags shown. Filters are active in the list.	Tags shown as active for selected filters. Unselected filters are greyed-out in the list.	Tags shown greyed-out. Filters shown as active in the list.

In T149435#2974853, @jmatazzoni wrote:

Secondly, I don't know how that normalizing behavior would work once we get rid of the need to press Show. I mean, what, you'd have to make it so that when the user selected the last filter in a group, the others would toggle to unselected. I don't think we want to go there. @Pginer-WMF please weigh in.

I didn't knew you had to click "show" for the filters to apply currently. More comments below.

In T149435#2974897, @Mooeypoo wrote:

If the normalization happens only once (when you load the page, or reload a previously saved state) it is a lot less of an issue (and more of a POSITIVE correction) than what we see right now with using the "show" button.

We expect users to move back and forth between the list of recent changes and inspecting the info about those changes. Some of the filters such as namespace and tags will still require the user to click on "show". I guess those would count as page loads and they would happen as part of a single user activity for the user.

Making automatic changes in the name of the user can interfere with legitimate intermediate states for the user. For example, the user may start looking for contributions only from newcomers and keep adding more experience levels to expand their scope by including learners and experienced. In this context, it is reasonable that the user will just keep adding filters from the group.
Later, the user wants to exclude newcomers, but the previous selection is gone (because he navigated or added a tag filter), and has to select learners and experienced again to exclude newcomers. The user can probably recover for such issues, but they can break the line of thought by the status changing automatically, and we may not need to do that.

(2) The vertical alignment of the filter label text and X is a little bit off? The text looks not vertically centered.

It seems to be fixed!

@Etonkovidova, I like your use of green checks for QA review in the Description. Very easy to follow.

@jmatazzoni Thx! Especially when a phab task is big, it's good to have some visuals of what's done.

When search finds matches, the first result is highlighted in blue. Pressing enter will select that filter (or unselect it if it is already selected). Up and down arrows will allow to select a different filter from the list of matches.

Should be fixed now.

Change 340543 had a related patch set uploaded (by catrope; owner: wikigit):
[mediawiki/core] RCFilters UI: Select filter when searching and add it on 'enter'

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

In T149435#3069280, @Mooeypoo wrote:

When search finds matches, the first result is highlighted in blue. Pressing enter will select that filter (or unselect it if it is already selected). Up and down arrows will allow to select a different filter from the list of matches.

Should be fixed now.

Your patch that I'm about to merge adds the highlight and enter behavior, but not arrow key behavior.

Change 340543 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Select filter when searching and add it on 'enter'

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

@jmatazzoni The following spec has been implemented except for "Up and down arrows will allow to select a different filter from the list of matches."

When search finds matches, the first result is highlighted in blue. Pressing enter will select that filter (or unselect it if it is already selected). Up and down arrows will allow to select a different filter from the list of matches.

The prototype does not have up-and-down arrow behavior. Could that behavior be implemented in a separate phab task?

To check the current behavior with blue highlighting: 1) In the filter search box type 'cat' (no quotes) - the 'Category changes' filter will be highlighted; press 'Enter' - the filter will be selected. 2) type 'user' (no quotes' - several matches will be found; the first match will be highlighted in blue.

QA recommendation: Product should weigh in.