Page MenuHomePhabricator

Only add highlight/toggle states conditionally to the saved queries
Closed, ResolvedPublic

Description

In RCFilters, saved queries save the 'highlight' and 'invert' toggles as part of their states. This makes it possible for a user to save a saved query with highlights and invert sates on or off.

Problem

However, saving that state indiscriminately also produces a few issues:

  • If the saved query is empty, for example, it will still save the state of the highlight/invert toggles. So, 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. The same is true for the invert toggle.
  • If the user added highlights into the system, and hten 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:
    • First, it means that the comparison query will not match if the user compares to a new state that never had highlights in them.
    • Second, (and this might be a pro or a con, depending on how one looks at it) when the user reloads this saved query and toggles the "highlight" to "true" the previous highlights will appear. This might be a good thing while the user is in the same session as the toggling-off of the highlight button, but it might be considered "noise" if the user reloads a query they saved without the highlights.

(The above is also the same problem for the invert toggle in relation to namespace filters)

Proposal

To fix this, I propose the following change to how we save saved queries:

  • If the user saved a query that has the highlight toggle in an "off" state, then the saved query should also ignore the highlights completely and save itself as if no highlights were ever chosen.
    • This means that while the user will be able to toggle the highlight button on and see their previously selected highlights in their current session, once they reload the saved query, the highlight selection is gone. It might seem weird, but it does follow saving what the user *literally* picked rather than an invisible state of the system.
  • If the user saves a query that has the highlight button in an "on" state but there are no current highlighted filters chosen then the highlight filter will be set to 'off' and the saved query will be saved without highlights.
    • This means that we might lose the 'show highlight' button state for this saved query, but it will retain the visible state of the system as before.
  • 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.
  • Followup: When we compare queries to current state, we use the same rules as above (if no highlights, highlight toggle is deleted from the comparison object, same for invert if no namespaces)
    • This will mean that the saved query will be compared to the visible state of the system and not whatever hidden "behind the scene" state that the model retained due to the user playing around or using different highlights or invert methods, or just forgetting about the toggle buttons altogether.

Details

Related Gerrit Patches:

Event Timeline

Mooeypoo created this task.Sep 28 2017, 7:09 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 28 2017, 7:09 PM
Mooeypoo updated the task description. (Show Details)Sep 28 2017, 7:11 PM

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.

jmatazzoni added a subscriber: jmatazzoni.EditedSep 28 2017, 8:53 PM

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

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.

jmatazzoni added a comment.EditedSep 28 2017, 9:16 PM

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

  1. Turn highlights off

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

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

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

  1. Now change filters in your screen, add filters, remove the existing filter, turn highlights on and choose a few highlights.
  2. 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.

  1. 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:

  1. Delete all filters.
  2. 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

Etonkovidova added a subscriber: Etonkovidova.EditedNov 27 2017, 9:30 PM

@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

jmatazzoni closed this task as Resolved.Dec 5 2017, 2:04 AM