I think there's a misunderstanding about what this task is asking for. It isn't about whether the default notification settings are good or bad, or about reducing or increasing notification noise. It's about making the default values visible.

Of the two options, the first one (newWithContextTitle()) seems like the clear choice:

The most advanced work on this is Change 1226855, which already has substantial work behind it, though it's currently blocked (Code-Review -1) and needs a rebase (there's a merge conflict against master).

Removing the "AbuseFilter" project tag and related tags, as I believe this issue is about system message magic word resolution globally, and not specifically about messages displayed by AbuseFilter.

Despite this being marked Resolved, the bug seems to have resurfaced. I just ran into the same "getDummyTitle" leak on frwiki mobile, which I reported as T437807.

This looks very similar to T247661, which is marked as Resolved — the underlying issue must have regressed since then.

Thanks for the pointers on the heuristic, @cscott — that's helpful context for both issues (the overly broad talk-page detection, and the leftover DiscussionTools markup on HTML headings that shouldn't be processed by DT at all).

I just noticed that GitHub tweaked their "confirm sensitive action" workflow, which I mentioned previously. As a reminder, it's their workflow for sensitive actions such as deleting a repository, similar to our re-auth flow, except that to ask for the credential, it navigates to an intermediate page instead of opening a popup in a new browser window.

Please note that a while ago (more than 3 years ago, before I was even using AI) I started working on this locally, and quickly realized the current regex-based approach wasn't sufficient — it fails on a handful of edge cases.

I renamed this task title to drop the reference to the other task ID — having both numbers in the title made it harder to filter this task apart from the other one in my email client.

Given that following my initial report it was revealed that the issue comes precisely from CSS comments, yes, switching to Less comments is also a viable alternative.

@Krinkle Thanks for pointing these out. That explains a lot — it's the CSS comment that's actually causing this. As similarly shown in the second screenshot in the OP of #4276, the docblock comment should ideally be preserved, positioned right before the ruleset it describes. But since this is an upstream issue, all we can do on our end is sidestep it for now.

Just to confirm: this is the lowest-hanging fruit (and a bit of an unexpected one), since it's both the costliest and the most directly fixable.

Change 1251065 introduced this selector in temporaryaccount.less:

Quick measurement on this page, using Chrome's Performance > Selector stats — they are the top 2 costliest selectors:

In content.media-common.less, the following:

Regarding the popup sizing: on the edit page, I notice the placeholder/interstitial shown while the popup is open is sized to roughly match the popup window's dimensions (at best). Not necessarily very useful in itself, but a nice touch nonetheless.

Thanks to @Johannnes89 and @Bugreporter for bringing up prior incidents (the 2018 admin account compromises, the Commons common.js cryptominer compromise). That context is genuinely useful and shifts the perspective here — this isn't a purely hypothetical risk invented after one unusual 2026 event, there's a track record of privileged JS/CSS access being abused before any of these mitigations existed.

I'd like to add a bit of perspective here as an aside.

Apparently it wouldn't be technically feasible to have an HTML reauth popup integrated into the same page while still maintaining proper CSP protections.

I just noticed that the reauth flow is no longer triggered when opening the edit page, but instead when clicking "Publish"; note that there was no indication on this ticket of this change (no reference to a Gerrit change), and it was only a comment above that tipped me off. This is a change in the right direction.

I just noticed that the reauth flow is no longer triggered when opening the edit page, but instead when clicking "Publish"; to be fair, there was no indication of this change on T197137 (no reference to a Gerrit change), and it was only a user comment that tipped me off. This is a change in the right direction.

Argh (again). Even though I pointed out that this patch was going to be inadequate, given the current state of the workflow — the icon being shown at the wrong point in the flow (i.e. after the user has already hit the re-auth wall, not before) — it got merged anyway. Yet another instance of this whole situation being handled poorly.

In addition to the horror already added by Gerrit 869274:

On a related note, and as a reminder to self (though others are welcome to fix this as well):

I can also reproduce.

This hook has been added by Change #1136810 (T392029). @MusikAnimal, could you take a look at fixing this? The change is simple and I provided the code just above.

Looking at the two linked patches, neither actually addresses the substantive concerns raised throughout this thread.

That said, this only holds if the popup is properly implemented — notably with proper Same-Origin Policy isolation. But even then, there are simple ways to defeat the overall protection without breaking SOP itself, which I won't disclose here.

See also: T197137#11827745

In T197137#12037776, @Tgr wrote:

Anyway it's helpful to differentiate between people not listening to you and people listening to you but then still disagreeing. The latter unfortunately sometimes happens, especially when considering tradeoffs - software engineering is not like math where any two reasonable observers are expected to agree on whether a statement is provably true. There will often be subjective decisions about site security, the Wikimedia Foundation has hired security experts to make those decisions, and sometimes the experts will disagree with you. Such is life. Having the word "security" in one's job title or being employed by the WMF doesn't necessarily make somebody right, but neither does being the last person repeating your arguments ad infinitum after everyone else has given up on the discussion. Better to just agree to disagree on what's the correct decision, and spend the energy instead on trying to find new ways to reduce the friction that the new security measure introduces to your workflows.

In T427957#11979126, @Tgr wrote:

Elevated security might expire between the button being generated and pressed (for a complex edit the time difference might be large) but I guess there is not much that can be done about that.

Thanks for the pointer to T417531, @cscott.

I was about to indicate that on frwiki this happens across the whole Wikipédia: namespace (and a few others), including our home page — but I just noticed a change that landed today:

I fully agree with the comments on this ticket expressing that the handling of this situation has been, and continues to be, a disaster.

Fair point, and longer-term that's probably the cleaner direction. But FullEntityParserOutputGenerator does more than bootstrap that JS — it also generates the title HTML, alternate links, and statement data updaters (image links, geo data, etc.), plus the actual SDC HTML via DispatchingEntityViewFactory, which already dispatches to MediaInfo's own views. All of that is needed on File pages.

Resolved by change 1071284.

As a follow-up to my previous comment: I'm having a hard time understanding why, in certain namespaces (e.g. Wikipedia:), headings end up carrying DiscussionTools-related markup (ext-discussiontools-init-section, data-mw-thread-id, etc.), even on pages that are clearly not talk pages.

I'd like to note that Gerrit 1295065 introduced a subtle, but problematic change in a specific case.

First, a big thank you to @Nux for finally pointing us toward a resolution — this bug has been open since October 2022, and the proposed guard is the clearest path forward anyone has laid out.

Regarding this specific link (as opposed to the broader footer issue):

During the review of the global preferences integration in Gerrit 1036781, two closely related issues were identified regarding how local preference overrides (-local-exception) are handled in the database. Both issues lead to orphaned or redundant rows accumulating silently in the user_properties table.

In T426452#11933884, @Jdlrobson-WMF wrote:

@Escargot_rouge it might be challenge to use a bot as you'd need to be careful not to overcorrect. For example you wouldn't want to update "upright" in a paragraph of text that read "The train had 43 passengers onboard and remained upright when a lone car went off the track."

I've had a closer look at the code, and it seems technically feasible to implement magic words that are precisely targeted, by acting within the braceSubstitution method.

See also my comments in T14974, where I had independently noticed and reported this exact behavior.

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).
That's what GitHub does for sensitive actions: it just asks you to re-enter your password to confirm.

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 starting from Special:Preferences, but that’s not the case right now — it doesn’t even seem to be reachable from there.

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 execution of JS from wiki pages when editing certain pages within the MediaWiki: namespace, as mentioned in PerfektesChaos's messages above:

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 <del>SpecialMostLinked</del> SpecialMostLinkedTemplates 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).