Fri, Sep 22
Thu, Sep 21
...and he's already done it: https://gerrit.wikimedia.org/r/#/c/379664/ . I will review shortly.
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.
Wed, Sep 20
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
Tue, Sep 19
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.
Thanks! It looks good to me but I'll let @Mooeypoo make the final call, she wrote most of that code.
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.
Mon, Sep 18
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.
Thu, Sep 14
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.
LGTM. Didn't test though, maybe @Etonkovidova can do that now that you've put this on beta cluster?
Wed, Sep 13
Tue, Sep 12
@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.
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.
Mon, Sep 11
@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.
Sat, Sep 9
Wed, Sep 6
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?
Tue, Sep 5
Aug 18 2017
Also, why did you diff en against es? They have the same behavior on Special:Notifications (both work) for me, while fr is broken.
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.
Aug 17 2017
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.
Aug 16 2017
(Downgrading from UBN to High on the assumption that only one special page is broken)
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?