Right now, the preference for "limit" (number of results) is misleading -- it pretends to only affect RecentChanges but, in fact, it affects the number of results in multiple places that are not outright specified.
For that reason, the "sticky" preference in RCFilters uses a separate hidden preference that takes its initial value from the preference page, but then changes its own value continuously on its own.
The result of that, however, is this:
- if the user has, in their Preferences page, the limit set to 10 (that is the limit everywhere, including RecentChanges RCFilters)
- Then the user goes to RecentChanges with RCFilters and sets the limit to 42 (Now the limit everywhere is still 10, but RCFilters' limit is 42)
- Then the user goes to Preferences page, and changes the limit to 95. (Now the limit everywhere is 95, but RCFilters' limit is still 42)
This can be confusing. We need to solve this. There are several options:
- Don't make RCFilters' limit a separate preference. This means that changing the number of results on RCFilters will also change the original preference.
- Cons: Every time a user changes the number of results for RecentChanges, they actually change it everywhere else too.
- Pros:
- It's straight forward and will always reflect what the user sees in the preferences page.
- It's the way things work right now, even though that's confusing
- Make the RCFilters' preference be 'null' if it is equal to the preference in the Preferences page. This means that if that's the case, the RCFilters' preference will, at least, be updated if the user changes the preference in Preference page, unless the user actively and purposefully changed the limit to something else.
- Cons: It's potentially confusing with the current preference text (but we are going to change that...)
- Pros: At least the user can have consistent updating of the values when they replace the results.
Whatever we decide, we also need to make sure that the UI displays the values that we consider valid; that is, the base array of options + the custom value from the URL, if it exists + the value from the user default. If the default is singular (the same as the Preference page) then it's one value, but if it's split, we should display both values, so the user can return to equalizing the value between the two defaults.
It sounds like #1 may be the most straight forward, but, seriously, we need to update the text of that Preference on the preferences page, because right now it's under the "RecentChanges" tab, making it sound like it's only affecting RecentChanges when it totally isn't.