I do the steps above and createTagItemWidget doesn't seem to get called. Anything else in the state of the UI that maybe you didn't mention?

I have a wip patch to NOT trigger a reload when an action results in changes to highlights only. It doesn't address the createTagItemWidget part but still makes a difference.

I will rebase and publish it when @Mooeypoo's big patch lands.

@Catrope is meant to be writing this to make it broader.

The commit prevents reloading if the removed tag is only highlights.
I couldn't reproduce the createTagItemWidget issue.

Change 383738 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Don't reload when removing highlighted item

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

The following operations can also be "highlights" only

• clearing
• restore defaults
• apply saved query

Do we want to address them in this ticket as well?

So I actually started working on something like that, but ended up unsure if it actually will be faster...

The problem with these, is that they're not always "highlights only". We always have to check whether there's a *difference* between the current filter-state and the new filter-state and only then know if the only difference was applying/removing highlights. I have a WIP with an idea for that, but it became a bit convoluted and I wasn't sure it would end up being worth it. I can post it so we can discuss.

Consider this scenario for example -

Case1:

• Your current filters are [filter1]
• You apply a saved query that's ONLY highlights
  • This is not actually "highlights only" application, because by applying this saved query, you dismissed/canceled [filter1].

Case2:

• Your current filters are [filter1] and [filter2], but [filter2] is a subset (so it doesn't actually affect the results
• You apply a saved query that's [filter1] and some highlight
  • This is basically a "highlights only" operation... but can we tell easily?

My idea was to try and solve the "easiest" cases where we can compare states and see if anything changed in the actual state and then decide if we should reload or not. I have a work in progress, but again, it became a bit weird to compute and I am not sure if it will be worth it -- I am going to take another stab at it (I think if I check *filter* state rather than compare parameters, it will work, but that will mean making a conversion every time, again) and we can see if it makes a real difference.

Change 383893 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Don't reload the list if the change was highlights-only

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

Change 383738 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Don't reload when removing highlighted item

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

Checked in betalabs and wmf.4 - adding/removing highlight to displayed set of of filters does not reload the results.

Regarding the cases that @Mooeypoo listed. they are essentially the different states of the results set and it seems logical that the result set reloads.

Change 383893 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Don't reload the list if the change was highlights-only

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