Apologies—immediately after posting, I realized that the <noinclude> technique wouldn't actually work here.

This bug is literally 18 years old and remains one of the main caveats for template work. Some action has to be taken; otherwise, how long will it remain stalled—indefinitely?

This issue could be similar to what I previously reported regarding 2FA reliability:

To address the concern that a script on the main domain can still forge POST requests or sniff tokens (as mentioned in point 2 above), one potential path worth mentioning is moving sensitive edits to a dedicated, "naked" domain (e.g., secure-edit.wikimedia.org).

Furthermore, automated edits take—what—well under a second, right?

In T197137#11827850, @matmarex wrote:

TOTP is by far the least convenient 2FA setup we support :) The only good thing about it is that it's low-tech, since you can generate TOTP codes on any device you already have.

For convenience, a security key like Yubikey is much nicer (you only need to touch the dongle plugged into your computer), or a passkey, which can also be remembered by the browser.

How about only asking for the password? That should be sufficient, right? Not even filling in the username and password — no, just the password.
In other words, switching from “re‑authenticate to confirm” to “type your password to confirm” (compatible with browser autofill, of course).

And another thing I just noticed: there should be a confirmation dialog before deleting a password…

Another related point: the Special:BotPasswords/<password name> page should include a subtitle breadcrumb linking back to Special:BotPasswords; its absence feels like a missing piece of the standard navigation.

Agree that Special:BotPasswords is difficult to find. I expected to find it somewhere in Special:Preferences, but that’s not the case right now.

Indeed, there are the edits using the JS API, and most of what is discussed here doesn't guard against them, although it's the most straightforward way of worm propagation. Adding safeguard steps to web edits (i.e., the regular form) adds little to no security if we don't guard against the primary attack vector.

I still prefer the "disable execution of JS from wiki pages" approach (though would it be sufficient?), but if "re-auth" is kept, we could reduce its friction:

The least-worst solution I see is to disable JS execution when editing certain pages within the MediaWiki: namespace, as mentioned in PerfektesChaos's message above. After all, we already do this on Special:Preferences without much complaint; at most, it causes a small surprise. There isn't really any JS so crucial to the editing process.

Argh, we are already struggling with so much friction from the current re-authentication timeouts. Adding a multi-person approval layer on top of that would just add more weight to an already difficult workflow.

I constantly have to "re-verify" and really, it's annoying AF. Especially as I have to go retrieve a TOTP code every time.

requestAnimationFrame() happens to solve the issue:

On frwiki, we have a script that acts on the "wpAutoBlock" checkbox (please don't mind the WIP state of the script at the time of writing).

I was still encountering the issue, and I’ve just resolved it by making an edit to MediaWiki:Group-sysop.js, which I noticed was included in the bundle, in order to trigger a server‑side cache refresh.

I've cleared my browser cache and restarted Chrome.

I'm still seeing the issue. The UUID is always the same, so I'm posting it here in case it helps:

As a reminder, as I suggested previously, there would also be the better solution of adding a hook for parser content:

It feels like we are over-complicating the core issue.

Right now, I’m still seeing the JS error in the console.

Same here — I only tested the styling itself, so the missing mediawiki.special load is an oversight on my part.

I'm raising the priority to medium, as the feature in its currently merged state is not functioning as intended, and a patch addressing the issue is ready for review.

I'm afraid that for this change to be effective, an $output->addModuleStyles( 'mediawiki.special' ); call also needs to be added to the SpecialMostLinked class (or one of its parent classes).

This patch has been merged, even though Bugreporter2 raised some concerns that are certainly arguable.

FWIW, I'm still currently encountering this error on frwiki, and it prevents my local custom JS/CSS files from loading.

From my understanding, the effect of this mistake is that -local-exception items end up being categorized as unused (by the following "else" branch), and would therefore be incorrectly removed when doing a reset with resetkinds=unused.

Thanks for checking in. I had to use the API because the preference in question isn't exposed in Special:Preferences.

• Base64 encodes data in groups of 3 bytes using 4 characters. Therefore, for maximum encoding efficiency, we should pick a number of bytes that is a multiple of 3. A sweet spot would be 12 bytes (96 bits), encoded using 16 characters (and as a bonus, 16 is a nice number). 96 bits is still sufficient for practical collision resistance, but I don't want to go below that since the "random ID" method relies on collision avoidance for correct operation.
• I've thought of an improved approach: we could store the generated random IDs in a set (O(1) lookup), and if an ID is generated twice, simply generate a new one (or, with a deterministic RNG, advance to the next value). This would even allow using a 32‑bit space while keeping the current [0-9a-f]{8} format; collisions would occur, of course, but they would be detected and avoided.
• I would be very interested to know whether intermediate markers affect page caching, because that would determine whether the correct method is to use true randomness or a deterministic RNG.

That being said:

The solution could be to use a deterministic RNG with a fixed seed.

To clarify, the random part I suggested here is not the same as the random part in the old marker format, from before Gerrit 214404.

An (almost) backward‑compatible solution would be to replace in these markers the incrementing “8 hex digits” part with 8 random hex digits. However, that would have only a 32‑bit space, which has far too much collision risk.

@SomeRandomDeveloper As you are not subscribed to that other ticket, in T357199#10290324 I suggested another approach that would have a better chance of being accepted (as it preserves context isolation): lazy‑loading the mw.* libraries on first call rather than cloning everything from the beginning… However, I don’t know for sure whether it would be technically doable.

Yay, another preference adding to the bloat. The usefulness‑to‑noise ratio here feels extremely low.

From an editor perspective, useformat=mobile should do what is written on the tin: render as on mobile. That means enabling MobileFrontend and using the default/only mobile skin, Minerva (unless a parameter useskin is also supplied).

This hardening should be applied to JavaScript mediawiki.util as well,
specifically into escapeIdForLink method (which is notably used by getUrl method).

Thanks for taking a look! I hadn't considered that the dependency was coming from another library — good catch.

It's been six months since I reported the font size issues in Vector classic caused by missing CSS variables like --font-size-medium.

Generally speaking, I abhor when websites, forums, or shops delete user accounts after some period of inactivity.

Currently, for registered users, the only option is still to use textContent, with a lookup for <bdi> to prevent breakage:

If we go the "username" route (note that it's exactly the same structure as my previous drafts):

The latest significant commits to the AbuseFilter extension seem to solely be about protected variables, afl_ip, afl_ip_hex, etc. That's why, as an educated guess, I assumed the regression might have been introduced during the work related to the items from this ticket.

I just noticed that a mw-collapsible-toggle-placeholder class has been introduced in the meantime. Refs gerrit 897905 and gerrit 1020287.

Hi @Pppery, I noticed the aside note I’d added was removed—no worries at all, I'm sure you had a good reason. It's been a while and I honestly don't remember the details well, so just curious what prompted the change. Thanks!

If you are interested in cleaning up additional remnants:

The removal of height: 22px causes the toolbar to occupy slightly more vertical space (exactly 22.292px in my current test). Previously, it was precisely 22px but slightly overlapped the textarea.

Refs related: Gerrit 1161826 — removal of the mw-toolbar-editbutton class (which appears to have been done a bit too hastily).

I have since identified other similar changes that need to be made, and I have opened a new task, T397496, to track them.

I have submitted patches for the first four skins. Regarding the fifth one, Skin:Chameleon, it is only hosted on GitHub…

Now that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/317079 was merged in 2018 (and in particular, see the changes at the bottom of this page), we should undo https://gerrit.wikimedia.org/r/c/mediawiki/core/+/373403 (which was merged in 2017): its CSS is now useless, as we are no longer inserting empty #toolbar elements.

Since it hasn't been brought up yet on this ticket, I wanted to mention that the AbuseFilter's rules editor also currently uses Ace Editor. What's particularly noteworthy here is that AbuseFilter rules are their own distinct language, not one of the standard content models being discussed for CodeMirror 6 support.

I think that no assumption should be made about the case of file_sha1, as it is subject to change without notice. Also, in the context of a hexadecimal string, "a" and "A" have exactly the same significance.

I explored alternative approaches using AI but couldn't find a better solution.

However, new_links introduces an ambiguity: it could suggest that the variable contains "new links" only, meaning "added links," whereas it actually refers to "all links of the new revision". The new_html, new_text, and new_size variables are less affected by this potential misunderstanding.

Thank you for the explanation. The USERJSPARSE_CACHE_VERSION is simply located in /includes/ResourceLoader/Module.php.

Interestingly, a user resolved the issue by modifying the relevant script to force a server-side refresh (he also first attempted a null edit, but that apparently did not solve the issue).

We have an issue on frwiki. Although we have been updated to 1.45.0-wmf.4 as expected, we are encountering this error:

I was using these graphs to monitor AbuseFilter performance—specifically, average execution time over time and conditions used (there is a hard limit of 2,000—previously 1,000—that is subject to being hit). Is there a replacement for this dashboard?

Refs the Tech News page: Tech/News/2025/23. (I'm not sure why this link hasn't been added to the task description, so I didn't include it myself.)

I used AI to tweak the announcement—you might find some of its changes worth picking up:

Looks like this is fixed now—turns out the change in SyntaxHighlight’s hook did the trick. Thanks to everyone who helped look into this! Closing the ticket.

Refs T58217, which had already identified discrepancies in prefixedText and nsText, fixed the former but not the latter.

In T380317#10428610, @Od1n wrote:

⚠️🤔 There is something I don't understand:

• The current value of this property is '' (empty string): as obtained with mw.title.new( 'interwikiprefix:Module:TestFramework' ).interwiki
• However, the relevant unit test expects the value 'interwikiprefix': TitleLibraryTests.lua#L296.

• I find the syntax with start/end parameters ({{trim:...|0|1}}) to be both awkward and uncommon.
  • Nevertheless, as I mentioned earlier, partial trims cannot be implemented since branches are automatically trimmed.
• The term "trim" encompasses two distinct use cases:
  • A) Trimming for template coding purposes: Here, we should only remove spaces, newlines, and occasional tab characters.
    • Indeed, I am fairly certain that some values contain leading or trailing non-breaking spaces that we do not want to trim.
    • Additionally, since this function will be used frequently, it must be highly efficient—Unicode handling would undermine that.
  • B) Trimming for editorial purposes (?): In this case, we could consider trimming all possible spaces.
• To start, I believe we should implement only the first mode (A).
  • If necessary later on, we could introduce a "mode" parameter: {{trim:...|BASIC}} (default) and {{trim:...|EXHAUSTIVE}}.
  • However, I am not convinced that mode B is widely needed. For rare cases, it could potentially be handled in a custom userland Lua module.

As a side effect of removing the troublesome hack, the bug in T387797 surfaced.

Just for fun:

Refs T387143, which solved the issue at hand.

I've just reviewed the patch code, and it looks pretty much ready. Maybe we could reactivate the patch, as it seems almost ready to be merged?

About ltrim and rtrim proposals: parser function branches are automatically trimmed, thus it may be difficult—and inconsistent—to implement these functions, as it would involve introducing some way to not trim spaces. Therefore, I'm not sure this would be a good idea.

ltrim and rtrim may be interesting proposals as well; however, these names are centered around left-to-right languages. A more inclusive approach would be to name them trimstart and trimend.

2025 here. 👋 I have just created T394604, and afterwards I noticed this ticket in a workboard.

Again on Vector classic, I just noticed another similar issue: on history pages, the font size of the "Compare selected revisions" button is too large.

On Vector classic, it seems that this changeset unexpectedly increased the font size of warning messages.

For quite some time now, a JavaScript error has been occurring on Commons. See T321532 for details.

I can easily reproduce this error as well. Come on, it's been occurring since 2022!

The wishlist request is not only about the "Find in page" browser functionality, it also seeks an easy way to uncollapse everything:

I have reviewed the lists of new features (Lua 5.2, Lua 5.3, Lua 5.4), and apart from the hexadecimal and Unicode escapes I mentioned earlier, I don't see anything particularly compelling. That said, I believe these escapes alone would justify implementing a newer Lua version.

Some interesting new features, related to multibyte strings:

• Lua 5.2 would let us use hexadecimal byte codes in strings, whereas we currently have to rely on decimal byte codes, which are very uncommon. Example: we could replace the very unusual \194\160 with \xC2\xA0.
• Lua 5.3 would even let us use Unicode code points in strings. Example: \u{A0}.
  • These code points are converted into their corresponding sequences of UTF-8 bytes (as outlined here). Keep in mind, they remain multibyte strings and come with all the associated caveats when using native string.* functions.