Thu, Apr 18
Wed, Apr 10
@Volker_E I'm not an expert and may be wrong/out of date, but aren't there either accessibility and mobile issues with collapsing? I vaguely recall DJ putting a lot of work in on that front. One issue I can see is that if you do use the form, the page applies the filters, but the box is collapsed upon reloading and there is no indication you are looking at filtered content without checking the url. Assuming people continue to infrequently use the filters it may lead to confusion.
@Jonesey95 I mentioned this in the link in T107069#5095549, but there was a block on pushing the latest version out (see email and T206678) that led to it being deployed Monday instead. This was listed among the many other changes in that version.
Tue, Apr 9
@Etonkovidova Did you see this from my original post?
To further clarify, I think that'd be fine if that was the primary point of the page. But this box represents an obscure action that's barely ever used and now its pushing the primary use of the history page to be below the fold.
Mon, Apr 8
@Xaosflux Agreed, but wasn't that the prior version (before ooui-ification) rather than an example?
Fri, Mar 29
Mar 22 2019
Mar 21 2019
Wouldn't it make sense to fix this first before going down the route of another user preference...?
Mar 20 2019
Mar 16 2019
Mar 7 2019
Feb 21 2019
Feb 18 2019
I think talk namespaces should be directly after the corresponding subject namespace
I alluded to this in my initial comment, but I actually think it's paramount.
@D3r1ck01 Pardon my ignorance, but it's not clear to me from that patch how this will affect items not in that list, e.g. Module, Book, Draft, Education Program, etc. Will it sort everything, or will it sort namespaces 1-14+100+101, THEN sort the rest? I ask because while namespace numbers may not be known to the average user, the order has been standard for a while and is roughly correlated with how useful something is to a user.
Feb 14 2019
Feb 7 2019
Feb 6 2019
Jan 30 2019
Jan 11 2019
@Tchanders No, this is good enough for me! Clearly mentioned at https://www.mediawiki.org/wiki/MediaWiki_1.30/wmf.12#Core_changes even if it didn't last long. Appreciate having the history.
@Tchanders That makes sense, thanks for clarifying. Was this change documented or noticed somewhere? I think it's a good solution, but was a jarring change.
Is this T213544?
I don't think this has been noted explicitly above, but manually deleting the target page (at least for me) let it go ahead just fine earlier today.
Jan 9 2019
Timing-wise, I suspect this is related to T208649, where the oversight block option is hidden in the same way.
Correct me if I'm wrong, but isn't this a duplicate of T209664?
Jan 4 2019
That's fair, though I only suggested the poor name to match, as with other elements. I stumbled upon it while looking at en:MediaWiki:Group-sysop.js, but perhaps it's best to just deal with inconsistencies en masse after everything is converted.
Completion? The other selectors all have 'em. This should be carried over into T117736 but it stands out here as is. It'd be nice for anything wanting to access it to avoid $('input[name=target]'), as id is preferred for user scripts.
Dec 21 2018
Dec 18 2018
FWIW Modern has a related issue, where they wrap underneath but aren't shown
Dec 15 2018
Unlikely, not a good way/place to deal with theme mismatches
Dec 13 2018
Dec 12 2018
Dec 5 2018
It'd be nice, if possible, to pair a solution for this with a fix for T23272 rather than mirror the issue there (i.e., checkboxes prevent display of oversight status to oversighters).
Nov 30 2018
@Daimona Not to further complicate your work on this, but one thing that is nice about the bulk revision delete system on history pages is that, if an item is already hidden and is then attempted to be hidden as part of a bulk revdel action, the page reports the error on that item but makes the change on all the remaining revisions just fine. Would this have a similar behavior? I'm likewise thinking of T144096 and avoiding creating duplicate entries vis a vis T206945 or T206938.
Nov 28 2018
Moreover, it just adds unnecessary complexity. I could understand allowing it in phases for advanced perm holders as 2FA is required for each in turn, but that still seems needlessly complex. Tgr's one-two punch would help with most situations, and at the least wouldn't make anything worse in the compromised 'crat scenario.
Nov 17 2018
Nov 15 2018
@MusikAnimal Do you have dates/counts on those? In August and September I did a whole bunch of month-long queries and did some very long date ranges maybe a dozen times?
Nov 6 2018
@Daimona Correct, although to your last point, after deleting the page oversighting the deleted revision(s), the AF info was visible to a non-sysop.
@Daimona Thanks again for dealing with this. Am I correct that this doesn't apply on edits that have since been deleted? This is probably closer to T44734, but as far as I can tell, if a page is deleted, and if one of its now-deleted edits is then suppressed, if that edit had initially trigged an abusefilter, that entry it still needs manual hiding.
Nov 5 2018
Nov 3 2018
Oct 18 2018
Oct 17 2018
Please pardon me if I'm being naïve, but isn't the underlying issue that the AbuseLog doesn't follow revdel actions? In a perfect world, wouldn't AbuseLog entries/examinations of successful actions respect the revdel/oversight status of that action? This need not wait for that, but am I wrong in thinking that's the ideal long-term solution?
Oct 16 2018
Oct 15 2018
Sort of related to T44734,
Oct 14 2018
Oct 10 2018
Yeah, blank/non-blank seems to be the issue; compare https://meta.wikimedia.org/wiki/User:TonyBallioni/vector.js and https://meta.wikimedia.org/wiki/User:TonyBallioni/global.js — the message is correct, but loading the "unauthorized page" for a blank page (like with creating another user's js) rather than "view source" seems unintended.
Sep 12 2018
Sep 7 2018
OY nevermind, totally intentional.
Sep 5 2018
@MusikAnimal I didn't want to be presumptive and assign this to you, but I did mean to ping you.
Sep 4 2018
Aug 28 2018
I was also a big fan of this preference, but neither CSS option above fully returns the behavior, either leaving a long message or removing the link to one's talk page. To return to the previous, you'd need to add:
Aug 21 2018
Aug 20 2018
Aug 10 2018
I don't know about nuclear, but if that also fixed other things Isarra, then fabulous. What I was trying to suggest in T200148 was that altering the entire content box to tweak what was seemingly an issue of misaligned z-indexes between the notifications flyout and the toolbars appeared incongruent. Changing the coordinates setup is indeed easy enough, but then again it's not clear to me what else folks have customized that would change.
More anti-modern chauvinism!!1! (Thanks DJ, that's helpful — I put a stopgap into sitewide Modern.css, so it's certainly less now, more unbreak.)
Aug 9 2018
@Isarra Thanks for fixing this! I first noticed this as it affected the way my userpage displayed — easy enough fix, nbd — but what's the advantage of having position: relative in #mw_content (already present in Timeless, newly added to Modern) rather than removing it from or adding z-index: 0;to the toolbars, which seem to be the real culprit? Just curious, as it seemed backwards to me.
Aug 6 2018
Aug 4 2018
Jul 28 2018
@mb I (and the others) said it should link to the redirect. As in, when you put your mouse over a redirect, you get the redirect title, then the full popup for the target. If you click on the redirect title, it redirects you to the target, i.e. the redirect+target popup provides two links that amount to the same thing, which is a waste. If you want to go to the redirect, you need to click on it, get redirect, scroll up the page, and click on the "Redirect from" link. The appearance of the popup would not change.
Jul 27 2018
Jul 3 2018
Just to add, I likewise see significant improvements, thanks everyone! For the below URL and just over 6,200 pages, I'm seeing only maybe a second or two longer time than the old system. That's something like a 10-15 second improvement — Awesome!
Apr 19 2018
One of the recent interface changes seems to have solved this particular issue, but has left those same icons significantly more cut off and off-center.