First, this has probably always been this way. But no matter.

The solution, I think, is to allow this to work the way the we recently fixed the # of Edits control to work on Recent Changes, vis-a-vis the relation between the local control and preference for # of Edits (T174415). Which is to say:

• When the user sets the preference, the option on the Contributors page gets changed to reflect that preference. E.g., if the preference gets turned on, the local checkbox gets checked. (Also, various settings are changed on RC page and WL as well, as per T172757, under "Migrate “Classic ORES” users to New Filters ORES".)
• But if the user changes the local setting, then the local setting becomes sticky on Contributors (only), and stays as set, but...
• ...there is no upstream changing of the preference page, and the preference is not changed for RC page and WL. I.e., now the local Contributors page setting and the preference are out of sync.
• This state persists until such time as the user changes the preference again, at which point the preference overrides the local setting again, and the cycle starts over.

So from the Contributors page POV, whichever setting—the local control or the preference—was touched last sticks, until there is another change.

@Mooeypoo, @SBisson, does that sound right?

Change 398841 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ORES@master] Make Contributions ORES preference sticky

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

In T182911#3838702, @jmatazzoni wrote:

First, this has probably always been this way. But no matter.

The solution, I think, is to allow this to work the way the we recently fixed the # of Edits control to work on Recent Changes, vis-a-vis the relation between the local control and preference for # of Edits (T174415). Which is to say:

• When the user sets the preference, the option on the Contributors page gets changed to reflect that preference. E.g., if the preference gets turned on, the local checkbox gets checked. (Also, various settings are changed on RC page and WL as well, as per T172757, under "Migrate “Classic ORES” users to New Filters ORES".)
• But if the user changes the local setting, then the local setting becomes sticky on Contributors (only), and stays as set, but...
• ...there is no upstream changing of the preference page, and the preference is not changed for RC page and WL. I.e., now the local Contributors page setting and the preference are out of sync.
• This state persists until such time as the user changes the preference again, at which point the preference overrides the local setting again, and the cycle starts over.

So from the Contributors page POV, whichever setting—the local control or the preference—was touched last sticks, until there is another change.

@Mooeypoo, @SBisson, does that sound right?

I don't think a complex scheme with a sticky preference is needed here, or even a good idea. There's a control on the (old) Watchlist page that's almost identical, and it doesn't work this way. The Contributions one just has a bug that the Watchlist one doesn't have, and we know how to fix it because we briefly caused the exact same bug on the Watchlist.

In T182911#3845318, @Catrope wrote:

...There's a control on the (old) Watchlist page that's almost identical, and it doesn't work this way.

Isn't the difference between Watchlist prefs and some RC prefs, like this one, that this preference controls RC page, Contributions and Related Changes? So you can't just have the local setting knock the preference out. If we don't do the solution above, how will this work?

Change 399122 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ORES@master] Fix Contributions ORES preference and form override

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

In T182911#3845714, @jmatazzoni wrote:

In T182911#3845318, @Catrope wrote:

...There's a control on the (old) Watchlist page that's almost identical, and it doesn't work this way.

If we don't do the solution above, how will this work?

What @Catrope suggest is to have the following behavior:

• If Special:Contributions page is opened regularly (for example, using the link in the header), "Hide probably good edits" is enabled if we have hidenondamaging=1 in URL or the preference on RC tab is enabled ("Show only likely problem edits").
• If form is submitted, using the "Search" button on Special:Contributions page, filter is enabled if the we have hidenondamaging=1 in URL, disabled otherwise.

Since the above is slightly technical, I should try using different wording.
When you open the page, preference is respected, and "Hide probably good edits" is checked/unchecked accordingly. Then, if you want, you can change the state and have that new state applied. Next time you open Contributions page, preference is applied again. So, the state of checkbox isn't sticky. And we esentially only fix the bug of not being able to change state of "Hide probably good edits" when clicking "Search".

I have submitted patches for both approaches, so we need to pick one.

I've boldly gone ahead and merged the patch for the watchlist-like approach.

Change 398841 abandoned by Catrope:
Make Contributions ORES preference sticky

Reason:
Superseded by I837540e3dcbcc42

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

Change 399122 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Fix Contributions ORES preference and form override

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

Contribution page option "Hide probably good edits" works as expected - if unchecked, the checkbox remains unchecked after clicking on 'Show'.