Moving this to blocked, as per @Volker_E's comment. This is a standardization issue, and fixing/overriding it specifically in RCFilters may do more damage than good to overall support.

Bringing back to 'needs review' with the new fix.

In T172387#3607757, @SBisson wrote:

The patch above works well but it creates a weird situation: when you save the empty state as your default filter, the "Restore default filters" button is visible even though you currently have your default filters.

In T172387#3607757, @SBisson wrote:

The patch above works well but it creates a weird situation: when you save the empty state as your default filter, the "Restore default filters" button is visible even though you currently have your default filters.

Pinging @Volker_E and @matmarex on this; I took a look and I can shift focus into the popup when you open the popup, which then allows you to tab through the elements in there -- however, while OO.ui.ButtonSelectWidget miexes in OO.ui.mixin.TabIndexedElement, OO.ui.ButtonOptionWidget isn't -- so I can't set a tabindex for it.

Whoops. Fixed in this commit.

Should be fixed alongside T174734: Changes to namespaces are not highlighted as requested if 'Group results by page' is enabled

Some of the results seem to not be properly tagged with the 'mw-changeslist-ns-1' class in the backend. Fixing.

This most likely happened after we changed the saved queries title from "we don't care how long this is" to "trim it at 1 line". The display options make it hard to align now, but need to be looked into.

In T169613#3600870, @jmatazzoni wrote:

In T169613#3593044, @Mooeypoo wrote:

@jmatazzoni question/clarification; as @Mattflaschen-WMF pointed out in review, the current code will only work in Special:RecentChanges. I could make it work in all other pages (Watchlist and RelatedChanges) but the language of the tour is specific to "RecentChanges".

I am going to keep this as-is for now; if you want this tour to also be the same behavior for Watchlist or RecentChanges (this also applies to the "invite to the beta feature") then let's create a child task and make sure we have adequate wording for the tour displaying on the other pages.

@Mooeypoo, will what you've done work on Related Changes? That's the only other place we'll want this .No need for Watchlist. Thanks.

@jmatazzoni question/clarification; as @Mattflaschen-WMF pointed out in review, the current code will only work in Special:RecentChanges. I could make it work in all other pages (Watchlist and RelatedChanges) but the language of the tour is specific to "RecentChanges".

(from an IRC conversation) -

This sounds a little weird; the nojs CSS should override the number from the beginning, regardless of JS (without having to wait for load)

In T169613#3536768, @Pginer-WMF wrote:

In T169613#3534447, @jmatazzoni wrote:

@Pginer-WMF, I rewrote this to make it into a spec for developers and moved it to RFP. Please look it over to make sure it's correct. Also, if you need to provide any icons, etc (like the gear, perhaps?), please add them to the Description above. Thanks.

The spec looks good.
One aspect missing is when this would be removed, since at some point the new filters would be the normal experience, but we can create a separate ticket for that if needed.

The cog icon is part of the standard set of icons, which I think can be adjusted to any color in code. In any case, if a specific blue version is needed, I added it below:

advanced-blue.svg1 KB

Download

@Pginer-WMF Do you have a copy of the gear icon in the proper size/color? I couldn't find it (I was sure we used it before, but I guess I was wrong?)

I am not 100% sure of the reprecussions of this to other products, so I don't want to edit the actual code, but it seems like it's reasonable to expect that any time wikipage.content hook is fired, the popups should reset.

Moving to blocked, as this is waiting on two patches that are less urgent but need to be merged enough time before a cut to allow for rigorous testing.

In T170875#3566757, @jmatazzoni wrote:

@Mooeypoo please note the above new requirement. I know there is some complication in the structure of this page. Will that be possible without heroic efforts?

@jmatazzoni Took a look and said there's no problem with removing the icon if it's a hassle technically.

Just pointing out that we can't (and shouldn't, in general) have an icon inside the message text. This causes huge issues for translation and while we might be able to cheat the system to comply, it's going to affect a lot more than just this specific page; translators are going to have a big problem with the bit of text and handling it.

The indendation was the intended behavior according to the spec I understood, and reworking it is a pretty big mess because of the wya that the "enhanced" display works with big tables and "placeholder" cells.
@jmatazzoni looked at it on my computer yesteday and seemed to be happy with it.

Whoops, my CSS selectors were too broad. Fixed in this commit.

We're looking into this.

I am looking at https://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:Posledn%C3%AD_zm%C4%9Bny and I can see the MediaWiki:Recentchangestext message clearly.

In T173264#3544061, @Pginer-WMF wrote:

This particular pushpin instance was intended to be presented more like a marker than an action (T164128). Some adjustments that could help:

• Make the size smaller. In the spec I was proposing to use 16x16px instead of the current 24x24px.

Done.

• Use grey as the color. We can use Base20 (#54595D)

Can't directly change the color, so I've used opacity instead. opacity:0.5; seemed to be fairly good, but may require a little bit of adjustment later.

• Use it as a shortcut for opening the menu, where the "default" status can be adjusted from. This provides a safe path for those trying to act on the mark to access related actions.

Done.

Okay, I misunderstood - I thought you meant reducing both top/bottom margins to 4px. Fixing the patch now. We can go over it again after it's merged and you could see it in beta.

In T173264#3544061, @Pginer-WMF wrote:

This particular pushpin instance was intended to be presented more like a marker than an action (T164128). Some adjustments that could help:

• Make the size smaller. In the spec I was proposing to use 16x16px instead of the current 24x24px.
• Use grey as the color. We can use Base20 (#54595D)
• Use it as a shortcut for opening the menu, where the "default" status can be adjusted from. This provides a safe path for those trying to act on the mark to access related actions.

I made the spaces smaller, removed the top margin (it was there to separate from the community list, but that list goes into the box anyways now) and I reduced the top margin/padding of the first heading of the results, so it's a little less spacey.

Yes, this isn't really a bug - or rather, it's expected.

After talking to @jmatazzoni, I'm closing this as invalid.

It shows the singular version of the message: "Show last change" (note, it's a single change)

Is this ready? Sounds like it depends on the pagination patch first?

Fixed the minimum cap to 0 rather than 1, since the backend seems to do that for us too, and we should be consistent even if it is stupid.
(We should fix this in the backend, but that will change current behavior. @Catrope?)

In T166919#3492306, @Pginer-WMF wrote:

In this particular case, I wonder if it makes sense to move the focus to the expanded elements. That is, clicking to expand moves the focus to the first link there (and as a side effect removes it from the button). @Volker_E
may know better if this is a legitimate approach or goes against the accessibility guidelines.

#1 and #3 are already fixed. #2 might not be that relevant since we've added 'hours' vs 'days' to one popup, and 'group by results' to the second, so since both have more than one picker, I don't think that a dropdown widget will work.

This is a simple frameless button. @Volker_E looks like a regression in ooui's frameless buttons with indicators?

Frameless buttons, in general, are supposed to be frameless, and they're usually inside other elements that don't take into account the "box" that is around them. The frame that appears on focus looks weird and abrupt on these types of buttons, especially when they're in the middle of some other box, which these type of buttons usually are.

In T166919#3492150, @Trizek-WMF wrote:

In T166919#3491046, @Etonkovidova wrote:

@Trizek-WMF the blue border appears in some other cases of UI elements (i.e. Legend expand link).

Well, it is still disturbing. :/

The arrow is misaligned this morning on Beta wiki:

In T171894#3491264, @jmatazzoni wrote:

@Mooeypoo, did you do just the Interim? Or is the rest of it ready to go as soon as the filters are ready (and should we make a separate task for the final state stuff?)

I couldn't reproduce #1 and #3 in that list of problems (whitepsace works for me, and tags work) but I did fix #2 (whitespace between the 'trigger' and the text)

It should be doing that for most cases because switching views also focuses the input -- but I made sure it does it on all cases as well.

This should be fixed; see T172156: Make limit sticky adhere to preference limit value

As per @jmatazzoni - making the 'limit' parameter non sticky for now.

I wouldn't say it's embarrassing, since the variable is sent in and there's no real use case to pluralize it in English -- but I did add that into the copy so TranslateWiki can verify that languages that require these are implementing it correctly.

In my opinion, #1 is the least confusing (though I am still very much meh about the fact the preference pretends to only apply to RC while it actually applies to everything) and also the quickest to implement.
I added a proposed solution above.

This is an annoying "feature" of the fact that the original preference updates everything that has lists of pages in it even though it claims to only update RecentChanges.