The two rules above will be reproduced the same for the 'invert' button if it's on or off regarding whether there are namespaces chosen.

Did you mean "the rule above", rather than "the two rules above"? The rule above (the second rule) makes sense: the invert state should not be stored if no namespaces were selected. But the one above that (the first one) doesn't make sense to me: if the invert button is off, but namespaces are selected, those namespaces are still meaningful and should still be stored.

@Mooeypoo wrote

...if the user manually clears all filters from the filter area but their highlight button is toggled "on" the query won't be recognized as saved even though as far as the user is concerned, what they are seeing is an empty query like they saved before.

I must be missing something. I don't understand this issue. Here's what I did, which sounds like what you're saying but must not be:

1. Start on the page with the defaults.
2. Turn on highlight button
3. Manually x out each of the default filters.
4. Save the empty state as "manual empty (highlight on)".
5. Hit "Recent changes" in the left nav to return to the default state (which seems to turn off highlight button, BTW)
6. Load the filter "manual empty (highlight on)".

Expected result: empty filters but with highlight button on
Actual result: actual as expected.

(It would be fine with me, actually, if the highlight button state weren't saved here. But it appears to be.) So what is the issue? Maybe you can describe what you are doing in steps?

In T177009#3644324, @Catrope wrote:

The two rules above will be reproduced the same for the 'invert' button if it's on or off regarding whether there are namespaces chosen.

Did you mean "the rule above", rather than "the two rules above"? The rule above (the second rule) makes sense: the invert state should not be stored if no namespaces were selected. But the one above that (the first one) doesn't make sense to me: if the invert button is off, but namespaces are selected, those namespaces are still meaningful and should still be stored.

Yes, good point.

@Mooeypoo wrote:

If the user added highlights into the system, and then toggled the highlight state off, what they actually see on the screen is filter query without highlights but the inner state still retains the highlighted filters, just with the highlight toggle on "off" state. This means a few things:

I'm not sure I understand this one either,. Here's what I did:
(With no special default saved)

1. Save a filter with highlights
2. Click recent changes in the left nav to return to defaults (with highlight button off)
3. Load the filter. the filter loads with highlights on
4. Now, turn off Highlighting

• Expected result: highlights disappear
• Actual result: as expected.

BUT

1. Follow steps 1-4 above
2. Now load the same filter again

• Expected result: the filter loads with highlights on
• Actual result: highlights remain turned off

BUT AGAIN

1. Follow Follow steps 1-4 in the first example
2. Now load a different filter that includes highlights

• Expected result: the #2 filter loads, with highlights on
• Actual result: as expected

So I'm not sure I see this bug either. What am I missing? I mean, it just appears that re-loading the same filter doesn't set your highlights to on. But loading a different filter will. So if the second exercise is a bug, it's a a small one? Is that what you're reporting?

What I am seeing is that I seem to have a default filter that I never declared as a default.

@jmatazzoni The issue is more about recognizing your saved query once you load it.

Consider the following scenario:

1. Add a filter to your active filter area. Now turn highlights on, and add a highlight for an unrelated filter (say, filterXhighlight).

What you see: Your filter area has one filter and one 'dimmed' capsule for the filterXhighlight. <EXPECTED>

2. Turn highlights off

What you see: Your filter area has one filter and that's it. <EXPECTED>

3. Save this as a saved query, say we call it "Only one saved filter". (The expected saved query is only one filter (without highlights))
4. Turn highlights on again.

What you see: Your filter area has one filter and one 'dimmed' capsule for the highlight you chose before <EXPECTED>

5. Now change filters in your screen, add filters, remove the existing filter, turn highlights on and choose a few highlights.
6. Now go to your saved queries and choose the query that you saved before - "Only one saved filter"

What you see: A filter area that has only one filter.

7. Turn highlights on

What you see: Your filter area has one filter and one 'dimmed' capsule for the filterXhighlight. <UNEXPECTED> This happens because when you initially saved your query, the highlights were off, but the data about which highlight you "played with" was in the system and was still saved.

Continue even further to see the problem:

8. Delete all filters.
9. Manually add the filter you know you selected for "Only one saved filter".

What you expect to see: The system should still mark this query as the one you saved, because it has the same result you expected (and saw) when you loaded it. BUT--
What you see: The system will not recognize this as a saved query, because in the saved query you also had a "hidden" highlight (even though the highlight toggle itself was turned off).

The problem statement and solution are meant to fix mainly the issue that is #9, and as a byproduct also result in

• Removing the confusing result in toggling highlights on again with #7 (where do these highlights come from? do you even remember they were the last you played with before saving this query? They're irrelevant...)
• Making sure saved queries are recognized properly
• Not storing "junk" information (like the fact you toggled highlights on but there were no highlights at all or the fact you had highlights but the highlight toggle was off) in the query

It makes the experience smoother and the result a lot more what you would expect from saved queries that you either load or get as default, if we strategically ignore the state of the highlight toggle, and clean up the irrelevant data that are the "background" highlights (that are there, but you clearly don't need them for the query if you toggled the highlight feature off)

Does that make more sense?

Change 382531 had a related patch set uploaded (by Mooeypoo; owner: Sbisson):
[mediawiki/core@master] RCFilters: refactor highlight state

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

Change 382531 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: refactor highlight state

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

@Mooeypoo 'Excluded' button active (invert=1) state still can be saved as part of the filter, for example the two urls below are two different filters:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&urlversion=2

https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&invert=1&limit=50&days=7&urlversion=2

Highlight seems to be fine (checked the scenarios you listed above with other testing).

Yes, the fix for that is here: https://gerrit.wikimedia.org/r/#/c/392182/

I'm waiting for input from @SBisson and @Catrope because I actually think we might want to do something slightly deeper, that @SBisson's "cleanup" patch may be doing part of anyways.

So yes, that part of the bug (saving saved queries with the invert state included) is not yet fixed.

Re-checked for the invert state - all work now according to the specs.

To summarize:

• clicking on 'Highlight results' or 'Exclude selected' button will make them active, but their active state cannot be saved in saved filters.
  • there is no hidden states with Highlight - the highlight only filter added and discarded (not saved) will not be stored anywhere and won't be recalled when 'Highlight results' is clicked.

QA Recommendation: Resolve