Jump to content

User talk:Suffusion of Yellow

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

HAPPY HOLIDAYS 2023

[edit]

FilterDebugger requests

[edit]

Would it be possible to import recent changes from multiple users and IP addresses at the same time? Similarly, would it be possible to have a checkbox to also import deleted edits? Thanks for all of your hard work on these scripts. Daniel Quinlan (talk) 23:38, 3 August 2024 (UTC)[reply]

If I can add another request here, it would be awesome if it was possible to see user-defined variables. Daniel Quinlan (talk) 19:53, 6 March 2025 (UTC)[reply]
@Daniel Quinlan: Not tested very well, but try switching to User:Suffusion of Yellow/FilterDebugger.dev.js. Instead of adding more vars to the dropdown menu, I added a more flexible "expression" option. Basically a second "mini-filter" that's run after the first, re-using the variables. So just plain myvar should give you contents of myvar but you can also do ccnorm(myvar), "test" rlike myvar, etc. Suffusion of Yellow (talk) 02:38, 16 March 2025 (UTC)[reply]
@Daniel Quinlan: Also  Done to both, also on the .dev branch. Separate multiple users, titles, or filter log ids with with pipes. I could only test importing deleted revisions on testwiki, of course, but hopefully it will work here. And I probably introduced a few new bugs. Suffusion of Yellow (talk) 00:49, 30 March 2025 (UTC)[reply]
Thank you so much. I've been heavily using the development version recently. The expression option has been helpful already. It allows variables to be defined using semicolons, but I don't suppose it would be possible to allow the input box to expand for multiple lines? Some expressions get a little long. I'll test out the multiple user support soon.
I am seeing some cases where the filter stops working properly (especially the results panel on the lower right) after changing the input several times and you have to completely reload the page to get it to work again, but I don't have any more specifics on when it happens at this point. Daniel Quinlan (talk) 21:13, 2 April 2025 (UTC)[reply]
@Daniel Quinlan: Working on a fix there. In the meantime, can you tell me what batch sizes you typically work with? Suffusion of Yellow (talk) 23:51, 4 April 2025 (UTC)[reply]
Sorry for the slow reply. 100, 500, 1000, and 5000 are the most common batch sizes for me. Larger than 5000 is insanely slow and more prone to fail. When using Recent Changes, I generally can't load more than a few hundred. Daniel Quinlan (talk) 22:02, 9 April 2025 (UTC)[reply]
By "insanely slow" which of these do you mean?
  • (A) It always takes a long time to retrieve the data from the server.
  • (B) It takes a long time to retrieve the data from the server, but only if you check "Fetch slow vars"/"Fetch all variables"
  • (C) It takes a long time to display the batch after the data is fetched
  • (D) It takes a long time to update the batch and statistics after you change the filter
  • (E) There's bad jank whenever you try to do anything
  • (F) There's bad jank only when typing in the lower "expression" box
(B) I can do nothing about; generating 5000 entries with new_html, page_recent_contributors, etc. from recentchanges can take up over 25000 API requests in the worst case.
(D) Obviously depends on the filter, but I get from about 1 ms / entry on a blank filter, up to about 200 ms on a giant regex like filter 614.
(F) Was a problem for me too, but should be fixed just now
I also reorganized the UI a bit. Might not be finished, there, but I was getting annoyed by the placement of some inputs. The "expression" boxes are now one-line Ace editors, and should expand to up to ten lines as you type. There's also a "remember settings" option. Suffusion of Yellow (talk) 22:31, 9 April 2025 (UTC)[reply]
I mean (A). 10000 feels like it's more than twice as slow as fetching 5000, but I haven't timed it. Now that 1301 (hist · log) exists for the type of testing I generally do with Recent Changes, the worst case with Recent Changes is going to be less of an issue. (C) and (D) is acceptable in general, especially after I finally upgraded my laptop. I get about 2.9 ms average after a change to filter 614 with 1000 filter 614 log entries as the test set.
Thanks for improving the expression editor. I'll check it out.
I'd have to see how the "remember settings" option works, but would a small preferences dialog be better? Most settings are pretty ephemeral. The only things I would probably change right now would be setting the default number of log entries to 250 instead of 100 when opening the debugger and disabling the automatic insertion of closing parenthesis, quotes, etc. by Ace (which I've been meaning to disable however that's done, but I haven't looked at it yet). Daniel Quinlan (talk) 23:00, 9 April 2025 (UTC)[reply]
Yeah, query parameters (filter, user, page, etc.) are (as before) stuffed into the browser history. But things like threads, short-circuit evaluation, line wrapping, and the two drop-downs on the left, are remembered. Ace settings (Ctrl-,) are not, but probably should be. I just discovered User:Nardog/CodeEditorAssist and I've been meaning to figure out how to get it to work with FilterDebugger. Suffusion of Yellow (talk) 23:10, 9 April 2025 (UTC)[reply]
The new development version is interesting, but it's so tall for my poor 13" screen (image will also show you what the dark mode stuff looks like, with a public filter, of course), even after moving the margin up 20px. I was already hiding several header elements. Daniel Quinlan (talk) 01:10, 10 April 2025 (UTC)[reply]
Um, I don't think I changed the height; it's been 95vh since forever so should (almost) fill any size screen one you scroll it into place. Are you saying that there's now no position that you can scroll to fit all of FilterDebugger in one screen (without clicking the fullscreen icon)? Suffusion of Yellow (talk) 01:41, 10 April 2025 (UTC)[reply]
But I am getting an annoying scroll up whenever I start typing in the main editor. This happens to me only in Vector-2022 on every textarea on Wikipedia, not just fdb. It's just that fdb was designed to fill the whole screen. I can fix the scrolling issue with html { scroll-padding-top: 0px !important; } (or something less aggressive) but I'd like to know why that's there in the first place. Is the Vector-2022 header sticky for you? It seems to be sticky on some pages for me, but not others, including fdb. Suffusion of Yellow (talk) 02:43, 10 April 2025 (UTC)[reply]
The height seems to be the same in my testing so it might be a mistake I made in moving my filter debugger styling from my browser into my common.css or perhaps it just seems taller now. Anyhow, on top of these tweaks, I'm testing this out:
.fdb-outer {
    height: 91vh;
}
body[class*="page-Special_BlankPage_FilterDebug"] {
    overflow-x: hidden;
    overflow-y: hidden;
}
That might be "too much" for general use, but it feels glorious: no scrolling or scroll bars except inside of the debugger panes and it uses as much of the screen real estate as possible without getting rid of the top header.
Vector 2022 has a sticky header that appears once you scroll past the title, but I don't get any scrolling when I start typing in a textarea. Daniel Quinlan (talk) 20:11, 10 April 2025 (UTC)[reply]
Thanks for the formatting fix, JJMC89. It was a bit off in the preview, but what Discussion Tools actually added was completely bonkers. Daniel Quinlan (talk) 20:35, 10 April 2025 (UTC)[reply]
Yeah, I don't want to start hiding too many elements outside of fdb by default. I expect everyone has their own preference as which elements to hide. I just changed the default size under Vector-2022 and Timeless to calc(100vh - 75px) which should make room for the header. But, the whole thing is resizable now (from the bottom), and if you keep "remember settings" checked, this size should stay the same on reload.
Also added your dark mode stylesheet (thanks!), but for the Ace editor I used the "Monokai" theme, which is the same as used on JS and CSS pages. Someone should probably file a phab about getting dark mode support in the Special:AbuseFilter editor. Suffusion of Yellow (talk) 01:23, 11 April 2025 (UTC)[reply]
Thanks for adding that. The dark mode detection logic in the development version doesn't work if the MediaWiki preference is set to dark rather than automatic. I think something like this will work better:
let htmlElement = document.documentElement;
let darkMode = htmlElement.classList.contains("skin-theme-clientpref-night") ||
    (htmlElement.classList.contains("skin-theme-clientpref-os") &&
     matchMedia("(prefers-color-scheme: dark)").matches);
Daniel Quinlan (talk) 02:41, 11 April 2025 (UTC)[reply]
Thanks again for the updates. I added a workaround for the above dark mode issue so I could do some more testing. Unfortunately, the Monokai theme isn't the best, at least for me. The high and low contrast colors make it hard to read, the 80-column margin is bright enough to be distracting, and it somehow even feels a bit slower (though that could be my imagination). It was pretty easy to update my CSS to work on Monokai, but you might consider making the theme configurable. Daniel Quinlan (talk) 03:44, 11 April 2025 (UTC)[reply]
Thanks, fixed the logic. I'll look at remembering some of the code editor settings. Suffusion of Yellow (talk) 00:33, 12 April 2025 (UTC)[reply]
That would be great. I'm not really familiar with Ace, but if there was a way for users to store Ace settings like the theme or setting behavioursEnabled to false in a userjs JSON-encoded option, it would go a long way. Exposing the editor instance might also be helpful. Daniel Quinlan (talk) 01:28, 12 April 2025 (UTC)[reply]

Filter variables to add to FilterDebugger and scripts that could use dark mode support

[edit]

In addition to the request above, there are a few filter variables that can be added to FilterDebugger:

  • user_unnamed_ip (Note: Do not add this to a filter until temporary accounts are available here, because this can mark said filter as protected forever)
  • translate_source_text
  • translate_target_language
  • sfs_blocked

Also, most of your edit filter-related scripts could probably use dark mode support, or similar:

  • batchtest-plus
  • FilterDebugger
  • filterDiff
  • filterNotes
  • filterTest

Thank you. Codename Noreste (talk) 21:56, 9 April 2025 (UTC)[reply]

I have a fairly decent dark mode stylesheet for FilterDebugger. I can share that somewhere if that's interesting to either of you. Daniel Quinlan (talk) 23:01, 9 April 2025 (UTC)[reply]
Yes please! Are we talking about the "official" Vector-2022 dark mode (which right now is just horrible), or the gadget (which is kind of low-contrast, but, at least, dark)? Suffusion of Yellow (talk) 23:18, 9 April 2025 (UTC)[reply]
I believe that would be the Vector 2022 dark mode, if I am not mistaken. Also, what do you mean that it's horrible in this context? Codename Noreste (talk) 23:45, 9 April 2025 (UTC)[reply]
In FilterDebugger, about half the screen is dark, and the other half is white, and the text is nearly invisible. Or are you asking if I think Vector-2022 is horrible in general? Well, consider that I went through the trouble of creating User:Suffusion of Yellow/AnonSettings just so I don't have to log in on my phone. Suffusion of Yellow (talk) 23:53, 9 April 2025 (UTC)[reply]
I'm "all in" on Vector 2022, but I have a lot of customizations. I just moved my dark mode changes for filter debugger and abuse filter from my local browser settings into User:Daniel Quinlan/common.css if you want to check them out. I wrote all of that very quickly so they could probably use a bit of cleanup, but it works well for me. Just a heads-up for anyone reading: parts of my common.css are tied to my common.js so it's best to go section by section. Also, note that the dark mode stuff would probably need to be wrapped in @media blocks (and possibly repeated for various modes) before it would be ready for general use. Daniel Quinlan (talk) 01:02, 10 April 2025 (UTC)[reply]
I just tried saving a filter on testwiki with user_unnamed_ip and got a big pink box demanding that I scroll down and check a confirmation box. I think that's enough warning, if someone includes it accidentally. I'll add them all. Suffusion of Yellow (talk) 23:35, 9 April 2025 (UTC)[reply]
 Done On the variables at least. Suffusion of Yellow (talk) 23:54, 9 April 2025 (UTC)[reply]

Edit filter on BLP Crime

[edit]

Thanks for your reply at Edit filter/False positives/Reports. That makes perfect sense, and I appreciate you taking the time to explain. Just to be clear, I wasn't so much worried that someone would complain about my edit, but that I had – inadvertently – actually done something wrong with the article. Very good to be reassured on that count. On the plus side: Had to read about Richard Jewell to understand your reference, so, you know, everything's educational! AukusRuckus (talk) 11:53, 23 March 2025 (UTC)[reply]

FilterDebugger question

[edit]

Hi SoY, I'm wondering why this isn't recognised as a match. Could you take a look? Thanks Nobody (talk) 09:32, 24 March 2025 (UTC)[reply]

Special:AbuseFilter/examine/log/23149595 shows no match either. All of the lazy-load variables, including added_lines, are missing, possibly because of phab:T176291 or a related bug. FilterDebugger doesn't try to generate any missing variables from AbuseLog hits; it only generates everything "from scratch" when viewing recentchanges, etc. Suffusion of Yellow (talk) 16:29, 24 March 2025 (UTC)[reply]
I think time could also be a reason why it doesn't show. If I run the Debugger against all hits from filter 702, all the non matches are before 3 February 2019. Not sure if anything relevant changed in the code around that time. Edit: It does look like that phab ticket was right around that time, culprit found I'd say. Nobody (talk) 17:28, 24 March 2025 (UTC)[reply]

Confusing FilterDebugger issue

[edit]

Hi Suffusion of Yellow. Maybe this will make more sense to me in the morning after I've had a coffee, but do you understand why the filter:

added_lines rlike "sigma\W+sigma"

doesn't match on these recent filter 614 log entries? If I change \W to [^\w] then it works as expected. I'm using the development version. Thanks. Daniel Quinlan (talk) 06:25, 14 April 2025 (UTC)[reply]

@Daniel Quinlan: A one-letter typo, that's why. Fixed now. Suffusion of Yellow (talk) 20:54, 14 April 2025 (UTC)[reply]

FilterNotes issue

[edit]

Hey there. Just popping in to let you know about a strange issue I seem to be having with FilterNotes, which is that I'm getting an error of "Failed to parse notes. Use 'Edit notes' button to view", appearing on every filter. Using edit notes does indeed show the raw notes, and adding notes works as usual, it's just an issue with viewing without editing. EggRoll97 (talk) 14:03, 17 May 2025 (UTC)[reply]

@EggRoll97: Thanks, seems to a be a MediaWiki bug; see phab:T394611. Worked around. Suffusion of Yellow (talk) 20:37, 18 May 2025 (UTC)[reply]
I also noticed another issue when using this script in dark mode - it has poor contrast which results in that you cannot see the text, and the links are barely visible. Codename Noreste (talk · contribs) 23:00, 4 July 2025 (UTC)[reply]
@Codename Noreste Thanks for pointing that out. Should support dark mode now. Suffusion of Yellow (talk) 20:14, 17 July 2025 (UTC)[reply]

Adding a default move display in FilterDebugger

[edit]

Hi Suffusion of Yellow. For move filters, would it be possible to add a (move) view that succinctly includes the most important information used by page move filters? More specifically, I think something like the expression: moved_from_prefixedtitle + " (" + moved_from_namespace + ") → " + moved_to_prefixedtitle + " (" + moved_to_namespace + ")" would be useful (perhaps with line breaks before and after the arrow). Daniel Quinlan (talk) 17:39, 22 May 2025 (UTC)[reply]

@Daniel Quinlan: Sorry for the late response. I just started implementing your suggestion, but now that I look at it, it feels kind of redundant. moved_from_prefixedtitle is exactly the same as the title in the header, so it's shown twice. And moved_to_prefixedtitle can be selected from the dropdown. Is having the namespace number really that useful? Suffusion of Yellow (talk) 20:52, 4 July 2025 (UTC)[reply]
No worries. Thanks for getting to it. I've found putting everything together on one line helpful visually although I agree it's somewhat redundant. I've tried without the first variable in the expression and it doesn't work as well and it looks awful. The namespace numbers are sometimes helpful for filters heavy on namespace numbers like 1354. The defaults of (diff) and (matches) are often not useful for move filters so perhaps it would be worth a broader examination. I was mostly just hoping for something easy to select that showed something more helpful than the defaults. I'm open to other ideas. Thanks. Daniel Quinlan (talk) 21:24, 4 July 2025 (UTC)[reply]

Potential update to FilterDebugger regarding a deprecated filter variable

[edit]

You might want to take a look at Wikipedia:Edit filter/Requested#all links variable now deprecated and phab:T391811, because all_links is now deprecated and new_links should be used instead. Thank you. Codename Noreste (talk · contribs) 00:27, 30 June 2025 (UTC)[reply]

@Codename Noreste: Thanks for the heads up.  Done Suffusion of Yellow (talk) 20:16, 4 July 2025 (UTC)[reply]

Precious anniversary

[edit]
Precious
Seven years!

--Gerda Arendt (talk) 07:29, 29 July 2025 (UTC)[reply]

Scripts++ Newsletter – Issue 27

[edit]

 You are invited to join the discussion at Wikipedia:Edit filter noticeboard § Merge proposal of filter 766 into filter 11. RaschenTechner (talk) 12:57, 8 August 2025 (UTC)[reply]

FilterDebugger log ID limit

[edit]

Hi Suffusion of Yellow. Would it be possible to avoid applying the default limit of 100 when a list of log IDs is manually entered in the box on the right? Or maybe provide some sort of visual indicator that the log IDs will be truncated? It's not a big deal if it stays as is, but I've unexpectedly run into this a few times. Thanks. Daniel Quinlan (talk) 01:17, 17 August 2025 (UTC)[reply]

 Done. Just ignoring the limit entirely when any ids are specified. Suffusion of Yellow (talk) 23:24, 30 August 2025 (UTC)[reply]
Thanks! Daniel Quinlan (talk) 00:07, 31 August 2025 (UTC)[reply]

FilterDebugger "too much recursion" error

[edit]

Hi Suffusion of Yellow. I ran into a "too much recursion" error today here (the error is more consistent with the 36726 version of filter 614). The lines causing the problem are the normalization steps next to /* first match is same as first match in removed text */. It looked like I had fixed with the current version, but the error comes back some of the time. Would it be possible to slightly increase the maximum depth allowed? I'm still using the development version of the debugger. Thanks. Daniel Quinlan (talk) 21:46, 22 August 2025 (UTC)[reply]

@Daniel Quinlan: That error is actually being passed through from Firefox's regex engine. Unfortunately, I don't know a way around it. Chromium takes over two minutes (!) to finish evaluating that one on my 15-year-old laptop, but it might be faster on your machine. Suffusion of Yellow (talk) 22:39, 30 August 2025 (UTC)[reply]
Ah, thanks for explaining. Is there a way to view the JavaScript regexes that get generated from filter regexes? And, if possible, can the transformation code be used from other scripts? (I want to write some test code.) Daniel Quinlan (talk) 23:50, 30 August 2025 (UTC)[reply]
I will probably put something up on GitHub/GitLab "when I get around to it". In the meantime I just the split out the regex module into its own page in my userspace. Try from your browser console:
let {PCiRE, RegexError} = await import ("https://en.wikipedia.org/w/index.php?title=User:Suffusion_of_Yellow/PCiRE.js&action=raw&ctype=text/javascript");
new PCiRE("foo|\\bbar").toString();
Suffusion of Yellow (talk) 00:24, 31 August 2025 (UTC)[reply]

 You are invited to join the discussion at Wikipedia:Edit filter/Requested § Reenable filter 1295. RaschenTechner (talk) 16:36, 13 September 2025 (UTC)[reply]

Fill my eyes is that double vision 2603:9001:4F00:1D63:A920:CDDC:EEA:8FCD (talk) 07:25, 29 October 2025 (UTC)[reply]

Guide to temporary accounts

[edit]

Hello, Suffusion of Yellow. This message is being sent to remind you of significant upcoming changes regarding logged-out editing.

Starting 4 November, logged-out editors will no longer have their IP address publicly displayed. Instead, they will have a temporary account (TA) associated with their edits. Users with some extended rights like administrators and CheckUsers, as well as users with the temporary account IP viewer (TAIV) user right will still be able to reveal temporary users' IP addresses and all contributions made by temporary accounts from a specific IP address or range.

How do temporary accounts work?

Editing from a temporary account
  • When a logged-out user completes an edit or a logged action for the first time, a cookie will be set in this user's browser and a temporary account tied with this cookie will be automatically created for them. This account's name will follow the pattern: ~2025-12345-67 (a tilde, year of creation, a number split into units of 5).
  • All subsequent actions by the temporary account user will be attributed to this username. The cookie will expire 90 days after its creation. As long as it exists, all edits made from this device will be attributed to this temporary account. It will be the same account even if the IP address changes, unless the user clears their cookies or uses a different device or web browser.
  • A record of the IP address used at the time of each edit will be stored for 90 days after the edit. Users with the temporary account IP viewer (TAIV) user right will be able to see the underlying IP addresses.
  • As a measure against vandalism, there are two limitations on the creation of temporary accounts:
    • There has to be a minimum of 10 minutes between subsequent temporary account creations from the same IP (or /64 range in case of IPv6).
    • There can be a maximum of 6 temporary accounts created from an IP (or /64 range) within a period of 24 hours.

Temporary account IP viewer user right

How to enable IP Reveal

Impact for administrators

  • It will be possible to block many abusers by just blocking their temporary accounts. A blocked person won't be able to create new temporary accounts quickly if the admin selects the autoblock option.
  • It will still be possible to block an IP address or IP range.
  • Temporary accounts will not be retroactively applied to contributions made before the deployment. On Special:Contributions, you will be able to see existing IP user contributions, but not new contributions made by temporary accounts on that IP address. Instead, you should use Special:IPContributions for this (see a video about IPContributions in a gallery below).

Rules about IP information disclosure

  • Publicizing an IP address gained through TAIV access is generally not allowed (e.g. ~2025-12345-67 previously edited as 192.0.2.1 or ~2025-12345-67's IP address is 192.0.2.1).
  • Publicly linking a TA to another TA is allowed if "reasonably believed to be necessary". (e.g. ~2025-12345-67 and ~2025-12345-68 are likely the same person, so I am counting their reverts together toward 3RR, but not Hey ~2025-12345-68, you did some good editing as ~2025-12345-67)
  • See Wikipedia:Temporary account IP viewer § What can and can't be said for more detailed guidelines.

Useful tools for patrollers

  • It is possible to view if a user has opted-in to view temporary account IPs via the User Info card, available in Preferences → Appearance → Advanced options → Tick Enable the user info card
    • This feature also makes it possible for anyone to see the approximate count of temporary accounts active on the same IP address range.
  • Special:IPContributions allows viewing all edits and temporary accounts connected to a specific IP address or IP range.
  • Similarly, Special:GlobalContributions supports global search for a given temporary account's activity.
  • The auto-reveal feature (see video below) allows users with the right permissions to automatically reveal all IP addresses for a limited time window.

Videos

Further information and discussion

Most of this message was written by Mz7 (source). Thanks, 🎃 SGrabarczuk (WMF) (talk) 02:47, 31 October 2025 (UTC)[reply]

ArbCom 2025 Elections voter message

[edit]

Hello! Voting in the 2025 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 1 December 2025. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2025 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:32, 18 November 2025 (UTC)[reply]