Sat, Nov 18
This was a mishap due to the fix for T177009: Only add highlight/toggle states conditionally to the saved queries
Thu, Nov 16
It will be a lot easier on me if you give me the full link from the history of the page you know, rather than having me spend time looking it up and building that link ;)
We just tried to reproduce it with various iterations - with wikitext, with the new wikitext editor, without, etc -- and none of us could reproduce it.
Wed, Nov 15
@IKhitron I have a theory that this has to do with the difference between editing in wikitext versus editing in VisualEditor. Since talk pages are always wikitext, that might be the cause.
Sat, Nov 4
Does it happen with any other page, or only your talk page?
Fri, Nov 3
Fri, Oct 27
Oct 19 2017
I see it now, sorry, I was confused.
Unless I remember wrong, the design dictated having a border when the box is open -- but having no border on the toggle button itself, so that explains why the border disappears when minimizing.
I don't think this is a good idea at all, and honestly, I don't see why this would be an issue to the users. You can access the same page by going to the same two versions of the address -- why does it matter that new data is added in? It hurts and harms nothing.
Oct 16 2017
Oct 13 2017
It seems the jumpiness on English Wikipedia's Watchlist is due to the dismissable links at the top, which caused 'jumpiness' regardless of RCFilters being enabled or not.
I can't reproduce jumpiness on Watchlist without those links.
The fix above corrects the jumpiness in RecentChanges; I couldn't reproduce the jumpiness in Watchlist...
The way the architecture is build, this is almost impossible to change now. Filters that are redundant are represented exactly the same way as not-being-selected in the URL, so whether you're refreshing the system (re-reading the URL) or reloading a saved query (which is almost the same as reloading a URL) the query is "normalized" for you.
This is dealt with here: https://gerrit.wikimedia.org/r/#/c/382531/
Oct 12 2017
So I actually started working on something like that, but ended up unsure if it actually will be faster...
Not sure if this is a tracking ticket but see related ticket for performance here: T178042: Code hygiene/performance: Batch filter update operations when we update multiple items
The commit prevents reloading if the removed tag is only highlights.
I couldn't reproduce the createTagItemWidget issue.
Oct 9 2017
I ran git-update and disabled and then re-enabled the role (vagrant provision in between of course)
Oct 7 2017
After looking into the accessibility and icons that we have, the icon we should be using is the 'info' indicator -- which was created for this purpose. Indicators are too small for the ? button and they also don't have the i18n fixes that we use for icons (so the ? will not flip where it needs to for arabic, for example)
Oct 6 2017
@Volker_E we need a question-mark indicator in OOUI to resolve this. It also seems to be a good idea in general seeing as we have an "alert" indicator "!" so there should also be room for a "?" indicator...?
Note: it's fixed in master by https://gerrit.wikimedia.org/r/#/c/382009 and will follow the train next week.
I manually updated composer afterwards in vagrant-ssh, and then ran foreachwiki update.php --quick and added the wg variables for ORES and it still didn't work -- but git-update is a good point that I completely forgot.
Oct 5 2017
Classes (@Amire80 please add/adjust if I missed any)
Yeah funnily enough, I presented this issue in one of my recent lectures -- we seem to be treating the search input as interface, and I actually think that's completely wrong. If you search a wiki, you usually search it in the content language, so in my opinion it should be content direction. But it's located in the interface area, so it automatically gets treated as interface.
Oct 4 2017
@IKhitron I tried to find exactly where the change came from and failed to find an exact match, but I think I know what happened. As part of the RCFilters fix, we've been updating the way highlighting works and the way that the enhanced list displays itself. 99% of the changes were done only for the beta activated, but while we were working we found a few underlying bugs that were also fixed. (The interesting thing about a bug, is that when it's a 7-8 year old bug, it's usually considered a "feature" even though it's clearly not... ;)
Sorry, a tiny addition that hopefully will make things clearer too:
Generally, turning the entire content block 'rtl' direction would impact the inputs as well, and having interface elements will be impacted by the interface direction classes -- so both of those should work out of the box without doing anything.
Sep 29 2017
@jmatazzoni The issue is more about recognizing your saved query once you load it.
Sep 28 2017
Sep 21 2017
Sep 20 2017
Sep 19 2017
Sep 18 2017
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.
Sep 15 2017
Sep 14 2017
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.
Sep 13 2017
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.
Sep 12 2017
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.
Sep 8 2017
@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".
Sep 1 2017
(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?)
Aug 31 2017
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.
Aug 30 2017
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.
Aug 29 2017
@jmatazzoni Took a look and said there's no problem with removing the icon if it's a hassle technically.
Looking at the text here:
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.
Aug 28 2017
Whoops, my CSS selectors were too broad. Fixed in this commit.