In T176380#3628928, @Etonkovidova wrote:

@Mooeypoo re-opened - the issue is still present in FF 55.

See also T176445: Systematically test load speeds of Watchlist and Recent Changes

Thanks for the detailed analysis @Bawolff and @jcrespo . My $0.02:

...and he's already done it: https://gerrit.wikimedia.org/r/#/c/379664/ . I will review shortly.

In T176445#3625843, @jmatazzoni wrote:

@Catrope, you signed yourself up to create a way to turn off Live Update. Whoever is taking on this task should be able to get going without that, but please coordinate with whomever you assign.

Does this happen only with the "New filters for edit review" beta feature enabled, or also with it disabled?

The above commit contains a bunch of fixes and tweaks that together eliminate reflow completely on my localhost (except for a very small horizontal reflow that is specific to the watchlist in enhanced mode), We'll have to see if it completely eliminates all reflows in production too, but I did test with large-ish community link sections, so hopefully it will, and if not it should come close.

In T176251#3622786, @Tacsipacsi wrote:

It’s quite easy to do by site CSS (the current 70% width is also done by site CSS), but I need some CSS classes to distinguish between the two versions.

In T176300#3623112, @Catrope wrote:

(I'll still propose that though.)

Proposed here: https://en.wikipedia.org/wiki/MediaWiki_talk:Watchlist-details#Proposal:_Move_help_links_from_MediaWiki:Watchlist-details_to_MediaWiki:Watchlist-summary

In T176300#3623053, @Catrope wrote:

I'll propose moving these links on the talk page.

In T176300#3622870, @TheDJ wrote:

watchlistdetails also isn't inside that min-height I think is it ?

In T176300#3622926, @jmatazzoni wrote:

@Catrope is this a dupe of some of the other tickets, or is this a task we'll want to prioritize for fixing before next week's release?

And should I change the title to "Fix page reflow on Watchlist and Recent Changes"?

In T176300#3622870, @TheDJ wrote:

watchlistdetails also isn't inside that min-height I think is it ?

This should be fixed in production now.

The patch makes the 'x'es appear, but they don't actually work in the new UI (neither in enhanced mode nor in non-enhanced mode). When you click the 'x' in the new UI in non-enhanced mode, it goes to a new page rather than using AJAX, and in enhanced mode it does nothing at all.

We mostly try to prevent the reflow by setting a min-height on the container that will contain the UI, but:

• That min-height value is just a little too low

In T173533#3620478, @TheDJ wrote:

Please think of T176300: Fix page reflow on Watchlist and Recent Changes when this gets done... combined, i'm sure they will account for a significant amount of 'misclicks' by people.

It's pretty simple: green is unseen. Both the arrows and squares turn green if the entry is unseen.

There's another area for improvement that @Mooeypoo has been working on: T173533: No longer block user from clicking results when page is loading.. Currently, we show a loading animation and an overlay over the results while the UI is loading, but we should really just let the user interact with the results list right away. The reason we currently do this is because in some cases (if the user has a saved query that they've made default), we may need to reload the result list and replace it with the result of a different query, because default saved queries are handled entirely client-side. Moriel is working on moving this server-side (T166908: ChangesListSpecialPage backend: Respect saved query if no parameters) and after that's done we can remove the loading thing from the results list.

In T176250#3619723, @eranroz wrote:

It looks like the RC sometimes very slow to load.

1. The above patch address only some of the slowness (the hidden UI creation can take ~1sec)

Thanks! It looks good to me but I'll let @Mooeypoo make the final call, she wrote most of that code.

In T176264#3619528, @Niharika wrote:

Where is the 'Grouped by page' option?

Looks like this only breaks in grouped ("enhanced") mode, in non-grouped mode it works fine.

I think he likely did mean RC, because he's a hewiki user and we launched RCFilters as a default there today.

All the copies are now done.

Clarification: this is asking for preferences to modify the base defaults (as they currently already do), not magically create a new saved filter as we previously discussed.

https://www.wikidata.org/wiki/Special:ListGroupRights#sysop now lists flow-create-board

My patch adds the following logic to the Flow config: if the Flow beta feature is enabled, or Flow occupies one or more entire namespaces, then give sysops the flow-create-board right.

In T175318#3605813, @Tigt wrote:

Unencoded " broke older versions of Android in my testing, mostly. Maybe they’re no longer common enough to worry about.

LGTM. Didn't test though, maybe @Etonkovidova can do that now that you've put this on beta cluster?

In T175318#3605777, @matmarex wrote:

In T175318#3605452, @Volker_E wrote:

@matmarex As the article and furthermore RFC 3986 in Appendix D.2 states :

but only ' is allowed in a URL.

If you want to follow the RFC closely, then spaces must also be URL-encoded. But we want to unencode them so clearly we're disregarding the standards and doing what works ;) I don't see why spaces would be okay to unencode but quotes not.

@Etonkovidova points out that I was wrong, two of them are used by contribs but one of them isn't. Also, we do still need the part of my change that takes the RC opt-out into account.

As @SBisson pointed out in code review, these preferences are all still used on the contributions page, so we can't get rid of any of them.

In T173613#3597163, @matmarex wrote:

I only see a HTTP 503 in the case that should return a HTTP 304 – otherwise, I correctly get an empty page with HTTP 200. Perhaps our caching layer doesn't like the 304. Try just using a HTTP 200 always and instead returning the information in the body (e.g. a '1' or '0')?

I also noticed that the code for hiding the RC-related ORES preferences when RCFilters is enabled didn't take into account the new opt-out preference, so I fixed that too.

I just approved the patch for T168376 and confirmed it works with that patch. I can opt into the beta feature but out of the RC page, and when I do that I get the old interface on the RC page and the new interface on the watchlist.

@jmatazzoni Not sure if this is a blocker for anything since we're rolling out the watchlist beta soon anyway, at which point this'll be moot.

Aha. But there are some fawiki occurrences too, although they look different.

Does anyone know which wikis this error happens on? For example, does it only happen on testwiki and test2wiki?

/w/api.php?action=flow&format=json&submodule=view-header&uselang=en&page=Special%3AUndelete&vhformat=html is a very weird request. Who or what would ever want to treat Special:Undelete as a Flow page?

Also, why did you diff en against es? They have the same behavior on Special:Notifications (both work) for me, while fr is broken.

In T173411#3534560, @Krinkle wrote:

ORES:/Hooks.php

	public static function onBeforePageDisplay( OutputPage &$out, Skin &$skin ) {
		if ( !self::oresUiEnabled( $out->getUser() ) ) {
			return;
		}

This might be our culprit. Although I was expecting to see a return false; here, given that, if I recall correctly, we changed it years ago that implicit return or null return defaults to true, not casted to false. And indeed, looking at Hooks::run() we only ever abort if either a string is returned, or explicit false (strict equality).

I looked into a few of these cases and none of these edits have entries in the ores_classification table even though they should. So it looks like ORES occasionally craps out or times out and a few edits go unscored.

I think we'll want to add a feature flag that puts RCFilters in either beta mode or default mode. That would make it easier to roll out the beta graduation to different wikis over the course of several weeks, as we plan to do.

(Downgrading from UBN to High on the assumption that only one special page is broken)

In T173411#3529276, @IKhitron wrote:

About regression: I'm 95% sure it was OK 19 days ago on this page.

Were you trying to view cross-wiki notifications in a no-JS environment? That is known not to work. The counter includes foreign notifications, but the no-JS version of Special:Notifications only shows local ones. There's a task for fixing that somewhere.

For some reason a LOT of modules are missing on Special:GadgetUsage. I think this might be a bug in the special page, not in Echo. Investigating.

As per the TechCom (FKA ArchCom) meeting on August 16th, this RFC is entering the Last Call period. Should no pertinent objections remain unaddressed by August 30th, the RFC will be approved for implementation.

@Harej What's the status of this? From looking at this task, it looks like it kind of lost steam toward the end of last year?

@Bawolff What's the status of this? At least from this task it looks like it's been stalled for quite a while?