Thu, Sep 21
Wed, Sep 20
Tue, Sep 19
Mon, Sep 18
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.
Fri, Sep 15
Thu, Sep 14
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.
Wed, Sep 13
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.
Tue, Sep 12
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.
Fri, Sep 8
@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".
Fri, Sep 1
(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)
@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?)
Thu, Aug 31
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.
Wed, Aug 30
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.
Tue, Aug 29
@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.
Mon, Aug 28
Whoops, my CSS selectors were too broad. Fixed in this commit.
Aug 26 2017
Aug 24 2017
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.
Aug 23 2017
- 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.
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.
Aug 22 2017
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.
Aug 21 2017
Aug 18 2017
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)
Aug 17 2017
Aug 15 2017
Aug 3 2017
Aug 2 2017
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?)
#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.
Aug 1 2017
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.
Jul 31 2017
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.