Page MenuHomePhabricator

Find a way to minimize the RCFilters URL
Closed, ResolvedPublic

Description

The RCFilters URL represent the state of the system, including highlight states. It's already quite big, but the more filters and features we add, the bigger it gets.

Beyond the issue of having super long URLs that are annoying to copy/paste, having such long URLs is wasteful and is hard to debug.

However, there are a couple of challenges with the URL that must be overcome:

  • The URL represents the state; we can't have it be ambiguous.
  • Different users should be able to share URLs and get the exact same result, regardless of what they have in their default settings.

Up until now, we took the above two points to say that the URL should always be complete and represent everything, so even things like "param=0" can override a "param=1" that user B has in their defaults.

But the URL is getting pretty big, and there shouldn't be a need for it. I've come up with an idea to fix this problem, but it carries a couple of technical and product implications that should be hashed out.

The provided patch gets rid of all parameters that are set to either empty or 0. Instead, we store an object representing the empty state of all parameters, and the model receives a merging between the URL and the empty state -- hence, it receives everything. Before we push the state to the URL, we once again remove anything that equals 0 or is empty.

This means a few things:

  1. On load, the system evaluates the URL and decides whether there are any relevant parameters. If there are, it loads the state from the URL. If there aren't, it applies defaults.
    • Potential issue: If the url has ?highlight=1 then you get an empty filter set with highlight enabled. Do we ignore highlight/nsinvert for the purpose of checking whether valid parameters exist in the URL, or is this an acceptable outcome?
  2. If I have defaults, whether they come from my wiki settings or a default saved query, the URL will adjust itself to present them. This means I can load RecentChanges, have the URL normalize automatically so I can copy/paste that URL to give to someone else and they see the same.
    • Note: Got rid of merging defaults everywhere. Default state should be loaded in initialization (if valid) or on user request. Otherwise, it should not be inserted into anything.
  3. URLs may look confusing to users, because of the way the filters work. If you only selected "Page edits" for example, the URL will change to show "hidenewpages=1&hidecategorization=1&hideWikibase=1&hidelog=1" (all the others in the group as 'hide' true) -- this isn't really a blocker, but we need to be aware of that.
  4. There is no way to get an empty filter set unless you enable 'highlight' (and even that may change, depending on bullet #1) -- is that okay? You can still remove all filters with the trash can, but if you load an empty URL it will prefill with defaults, so you can't load a URL that will give you an empty filter set as default.

We should make sure that all scenarios of ambiguity are solved or are known. Are the above issues okay, or should be fixed, etc.

Proposed fix attached below. It's marked as 'wip' so it doesn't get merged before at least solving bullet #1 and #4.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 15 2017, 11:40 PM

Change 353925 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [wip] RCFilters: Minimize url query

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

Re #1: ignoring highlight/nsinvert seems fine, but I also wouldn't object too much if you didn't ignore them.

Re #2: OK, so the URL remains empty when you load, it doesn't normalize?

Re #3: Yeah, that's how it works for b/c reasons, that's just how it is. We could fix that in the future if/when we feel like breaking b/c.

Re #4: Yeah that seems fine.

Per my comment in chat, I would have suggested using the global default state (i.e. defaults not taking user prefs into account) as the base instead of all zeros if I had seen this before you started writing code, not sure if that's worth changing now that you've already written it.

Mooeypoo added a comment.EditedMay 16 2017, 7:04 PM

Re #1: ignoring highlight/nsinvert seems fine, but I also wouldn't object too much if you didn't ignore them.
Re #2: OK, so the URL remains empty when you load, it doesn't normalize?

It does normalize to show you the defaults; this actually makes more sense user-wise, I think. The URL, for the most part, represents what you actually have on the screen. If you started with a blank query (direct to Special:RecentChanges) then your page will load defaults in and populate the query with the correct parameter representation, whether your default is from the wiki/preferences or from a saved query.

It makes defaults consistent regardless of where they come from, and makes the URL consistent regardless of what defaults you have set.

The only problem with this, as I mentioned before, is that there is no way (or almost no way) to produce a link that has *no* active filters at all, unless you save that as a saved query (ironically). If you want an empty set, you either need to save it as a saved query (and we need to allow for it - we hide the 'save' button right now for empty filters) *or* you need to load the page with defaults and then hit the "trash can" icon.

I don't see how many people will consistently need an empty filter set, though?

Re #3: Yeah, that's how it works for b/c reasons, that's just how it is. We could fix that in the future if/when we feel like breaking b/c.

Sounds good to me.

Re #4: Yeah that seems fine.
Per my comment in chat, I would have suggested using the global default state (i.e. defaults not taking user prefs into account) as the base instead of all zeros if I had seen this before you started writing code, not sure if that's worth changing now that you've already written it.

Yeah, I don't think it makes too much difference in terms of product. It definitely doesn't matter in terms of the code (you merge zeros or you merge defaults, it's the same operation to build the base object and merge it in/minimize.)

In terms of product, it's pretty much the same with the same pitfalls. If we use the "all zero" state, then if you have a large full-coverage group, then marking one will show in the URL all the other items in the group as hideA=1&hideB=1&hideC=1.
If you go by defaults, then you might not get that for a configuration where that filter is in the defaults, but then you will get a case where we override a 1 with a zero -- so you will get cases where you select another filter from that group and get a URL with hideC=0&hideA=0&hideD=0 so it overrides the base default.

Neither of those strike me as better.

The only benefit in using "all zero" state is that you know for a fact that the URL you're getting is always representing the state -- that is good for debug purposes, and to also allow users to share these configurations between wikis by sharing the query. It might not be a hugely needed or used feature, but since I see no actual difference bteween the two, it is a decent bonus to have for users who know what they're doing and want to share configurations amongst themselves. This will become even more needed as we add more filters that have highlights, because you might end up with still a fairly large URL query if you ahve several filters and namespaces highlighted.

BTW, another bonus in using all-zeros is that if anything needs to be demonstrated to others, it becomes straight forward. If I want to put a link on my user talk page to a certain Special:RecentChanges filter set, the link will work for anyone who clicks it, regardless of defaults. It will also work for the developers if we want to debug an issue with a specific filter set.

If I use defaults as override, then that shared link (even within a wiki) may look differently to those who have different preferences, or differently between logged in and logged out users, etc. Using the all-zero approach seemed to be more consistent.

I removed 'WIP' tag from the patch and fixed the 'highlight' parameter to be ignored when looking for emptiness.

Change 353925 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Minimize url string

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

Checked in betalabs:

  • and betalabs:

https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1

  • Check after the fix will be merged: bookmarking/copy&paste url with highlight (with or without filter selection)
jmatazzoni closed this task as Resolved.Jul 14 2017, 12:55 AM