Never let it be said that I bring only problems and never solutions. ;-)

Here are some solutions that would work for me:

1. Eliminate the ugly style altogether. Advantage: I'm happy. Disadvantage: A few people won't be.
2. Require password protection to change that pref, much like your laptop would require that you enter your password before doing an irreversible destructive action.
3. Don't carry that information in a URL. Editors with different preferences ought to be able to exchange URLs and still see the same information in their own preferred format.
4. Just stop secretly changing my prefs based on a URL. Either ask for confirmation ("Do you really want to switch to the ugly style?") or just leave my prefs alone, and treat the URL as a one-time aberration that applies only to that single viewing of the page.
5. If you're going to change my prefs based on a URL, then un-change them based on a URL, too.

In the meantime, I've adapted a script (with help) that previously set UI languages. I've tested it (once), and it seems to work. Anyone else who's bothered by this bug might want to consider putting this in your /common.js or /global.js user script page:

 /* Change RecentChanges layout to not-ugly */
 /* Remove if https://phabricator.wikimedia.org/T202916 ever gets fixed */
mw.loader.using("mediawiki.user", function() {
	if ( mw.user.options.get('usenewrc') !== 0 ) {
		mw.loader.load("mediawiki.notify");
		( new mw.Api() ).postWithToken( 'options', {
			action: "options",
			change: "usenewrc=0"
		} ).done( function() {
			mw.loader.using("mediawiki.notify", function(){
				mw.notify( "RecentChanges formatting has been reset.  You may need to change the URL to remove 'enhanced=1'." );
			} );
		} );
	} else {
		console.log('RecentChanges formatting was not ugly this time');
	}
} );

We have de-prioritized this ticket due to @Whatamidoing-WMF finding a work around and it not falling into the scope of things we are working on this FY.

It is never good to see a frustrated @Whatamidoing-WMF, and so in my explorations of RCFilters (in preparation for a planned hackathon project) I have decided to don my cape and try to help.

On a more serious note: The initial intent of this behavior was a hopeful one -- the idea was that when the user actively changes the filter states their decisions are "sticky"; meaning if you intentionally go into the visibility popup (under the filters) and actively change the "Group results by page" whichever way, then the system will remember this choice for you -- hoorah!

... Except that the system also tries to be helpful by reading the parameters given to it through the URL, and uses that to dictate the state of all the UI elements -- including (you guessed it!) the "Group results by page" checkbox -- which, in turn, automatically sets the preference for you. To be helpful.

So while the behavior is useful if the user chooses to change their view it's probably very unhelpful -- and, as I have witnessed in this ticket, very frustrating! -- to assume the user always wants that change.

Changing this behavior is a bit of a change for all from the current behavior, though, so I wanted to be a bit careful with it. I have therefore propose two things in the following patch:

1. The toggling of the "Group results by page" checkbox will never automatically set the preference. The user can decide to change the view but on subsequent (fresh!) views, their preference will count.
2. BUT to preserve the usefulness of having everything in the same place and to not force the user to go and search for a preference they likely won't know where to find, I have added a button underneath that checkbox that will change the preference default.

The above should fix the problem while still allowing users to change their preferences. I hope this is acceptable (it should likely be approved by the current product owner?)

One last note: Be aware that there is no way to change the fact that a URL can change the view for you. If you get a URL with "enhanced=1" (or the previous newrc=1 your page WILL change its format to the "grouped by page" view. This is not an RC Filters ("new") product decision. This happens in the no-js version ("old") as well. If we want to change that (it's possible to ignore that parameter) we need a wider agreement/thought about product.

So, @Whatamidoing-WMF I hope I am fixing your frustration -- though, it might not completely solve it.

I can hang my cape now.

Change 920369 had a related patch set uploaded (by Mooeypoo; author: Mooeypoo):

[mediawiki/core@master] Remove sticky preference for "enhanced" by default

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

Test wiki created on Patch demo by MSchottlender-WMF using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/0ec060d127/wiki/Special:RecentChanges

In T202916#8856979, @Mooeypoo wrote:
The above should fix the problem while still allowing users to change their preferences. I hope this is acceptable (it should likely be approved by the current product owner?)

Since Growth is the maintainer of Recent Changes, I believe that's me.

I have added a button underneath that checkbox that will change the preference default.

In general, this approach makes sense to me and I appreciate having the preference configurable in the moment of interaction, rather than buried in Preferences. However, the "Do this from now on" button either isn't working on Patch demo or doesn't match my UX expectations. When I click on Do this from now on, I expect to receive confirmation that something changed.

And some general questions, possibly for @JFernandez-WMF, @RHo, or @Mooeypoo:

• Should the Do this from now on option display if "Group results by page" isn't checked?
• Do we use the Do this from now on language elsewhere? Seems like "Update preferences" is more succinct.
• Do this from now on is styled more like a link than button, is that expected?

And since I'm not a frequent Recent Changes patroller, I'll want @Whatamidoing-WMF and @Trizek-WMF to give this a test and assess if this is ready to release and what level of communication is needed for this release. Thanks!

In T202916#8860587, @KStoller-WMF wrote:

In general, this approach makes sense to me and I appreciate having the preference configurable in the moment of interaction, rather than buried in Preferences. However, the "Do this from now on" button either isn't working on Patch demo or doesn't match my UX expectations. When I click on Do this from now on, I expect to receive confirmation that something changed.

There was never a confirmation, even in the current (pre-patch) state when it changed your preferences by toggling the checkbox, so I didn't think about this, but it's a good point.

I can look into adding a notification style confirmation ("toast" notification) after the preferences change.

By the way, this probably won't work on the patch demo because I was thinking only about testing the new UX, so I think I didn't build the patchdemo wiki with users (Oops?)... so it wouldn't be able to change the preference. I did test this locally and made sure it changes the preference itself but I can look into rebuilding the patchdemo in a way that it should work in demo'ing the behavior.

And some general questions, possibly for @JFernandez-WMF, @RHo, or @Mooeypoo:

• Should the Do this from now on option display if "Group results by page" isn't checked?

I would go with whatever you experts tell me is best, but I think that the preference can be toggled on AND off, so I'd keep it.

It is a bit of a weird toggle, honestly, because it pretends that it's a yes/no question but in reality, it's a choice between two possible (and distinct) visual modes. If we allow users to save their preference, I'd let them save either mode (meaning keep it there regardless).

I had an idea of only making it active if the value is different than the user's preference, but that became a bit more complicated for a patch that was meant to be fairly small so I gave up. I could try and look into that and see if it's worth the trouble, if you think it will be useful!

• Do we use the Do this from now on language elsewhere? Seems like "Update preferences" is more succinct.

Can change this to whatever is clear. I wasn't sure if "preferences" was not confusing within the context of the popup, but I think I was just overthinking things.

• Do this from now on is styled more like a link than button, is that expected?

Can change this to a full button. I thought I'd make it less prominent, but I'm deferring to y'all for design decisions. Can also add a cog ("settings") icon if that's useful. I was worried of overdoing it :)

The obvious solution to me is to save the preference only when the checkbox is clicked (i.e. not through the URL).

Came here to say the same thing. The most annoying thing about this was changing the preference by visiting a link someone shared with the comunity.
If I change it myself and come back later, it is fine to get what I chose to have before I left.

Okay, I have to admit, I completely didn't think about the option of only triggering the "save preference" when the user manually clicks the checkbox; I think in my mind I thought that the distinction (between explicitly clicking vs the programmatic change of state) wouldn't be as clear to users as to when the state is saved or not.

I think that doing that is the best solution, though, and as a bonus, also simplifies everything completely and removes the need for a separate extra button.

I've updated the patch to do exactly that -- things act and look the same, but the checkbox state is only saved in preference if the user explicitly clicks it.

Simple is best; I agree this is the better solution! Thanks, @Nardog @matej_suchanek, and @Mooeypoo!

How can we summarize what happens for someone who just land in this conversation? :)

In T202916#8870777, @Trizek-WMF wrote:

How can we summarize what happens for someone who just land in this conversation? :)

Yes! Once this patch is merged (it isn't yet; I'm hoping now that we're after the hackathon -- and that @KStoller-WMF gave her okay to this) the change is as follows --

Background
RCFilters automatically saves the view preferences that you set on the page; if you choose "group results by page" in the UI, it will also make it "sticky" and save that in your preferences so you have the same view when you come back to the page.

There was a bug that meant that if someone sends you a link where "Group results by page" was not what you chose in your preferences, then visiting that URL changed your preference. This was not great. This is now fixed with this patch.

The fix
From now on, "Group results by page" preference will only change if the user manually clicks that checkbox and will NOT change your preference if you view a URL someone sent you with a different setting.

Small caveat (about loading from a URL)
Loading RecentChanges or Watchlist from a URL has always loaded the "Group by page" definition that the link itself provided regardless of the preference you have. However; from now on, that state will not override your actual preferences.

Ha-ha, cool stuff! And food for Tech News. Thank you @Mooeypoo!

Change 920369 merged by jenkins-bot:

[mediawiki/core@master] RecentChanges: Remove sticky preference for "enhanced" status, make manual

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

I believe this is an accurate summary of the bug and fix. I have added it to the Tech News draft. Please fix it directly (within ~25 hours) if anything is inaccurate or unclear. Thanks.

Previously, clicking on someone else's link to Recent Changes with filters applied within the URL, could unintentionally change your preferences for "Group results by page". This has now been fixed.

In T202916#8896779, @Quiddity wrote:

Previously, clicking on someone else's link to Recent Changes with filters applied within the URL, could unintentionally change your preferences for "Group results by page". This has now been fixed.

Yup, that's exactly right!

Test wiki on Patch demo by MSchottlender-WMF using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/0ec060d127/w/