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.

Thankfully, there is some activity—the patch was recently rebased (patchset 4 on April 2nd).

Considering that there is a code that migrates the user preference,
and that all code related to "xlarge" have been removed everywhere else,
we should remove the remaining .mf-font-size-clientpref-xlarge in mobile.less, which seems to be the only leftover.

In T357197#10665117, @Krinkle wrote:

@Xover Note that browser requirements for the optional JavaScript layer are very different from browser requirements to render web pages (HTML/CSS). https://www.mediawiki.org/wiki/Compatibility#Browsers

Reminder to self: I have some local optimizations to tidy up and submit — most notably, avoiding execution of the #mw-abusefilter-syntaxresult DOM query on every character input. See ext.abuseFilter.edit.js#494 and ext.abuseFilter.edit.js#522.

Ok, it has already been fixed: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/10f306582cca6c9f8da989a91368beae8001dc19%5E%21/resources/lib/ooui/oojs-ui-core-apex.css

Currently, I observe the problem on frwiki and enwiki, but it appears to be correct on mediawiki.org. The latter applies an additional rule, box-sizing: border-box;.

An effect of this is that the « ﹀ Search for contributions » box, when collapsed, has an increased height, and the legend line is no longer vertically centered.

Please ignore the comment you are quoting. Even myself couldn't figure out a way to migrate the files if that path were followed.

Indeed, this template call returns « :<space> », so as its return value starts with « : », it's yet another example of an issue arising from the current situation.

About the wgMFMobileFormatterHeadings config item, which comes from $config->get( 'MFMobileFormatterOptions' )['headings'] and is documented here, see T110436.

I opened a dedicated ticket for that issue: T388083.

Done, here: T388083. Feel free to edit it.

tl;dr: 1) Ditch the terrible JS-loading of Mobile.css (for emphasis: keep this file). 2) Provide common files for desktop and mobile, we are awaiting for these files for way too long. 3) Relish the relief that is finally taking shape.

Alternatively: Add right now Desktop.css/js files (so, they would be loaded the same as Common.css/js). Leave some time to editors. Then bite the bullet and load Common.css/js on all platforms.

I know Common.css could be made loaded on mobile too. But I'm afraid it would be too much of a disturbance, considering how old the existing Common.css files are.

Hence what I am suggesting as a next step: providing a true common CSS, for both desktop and mobile.

It seems that this code needs to be updated, please have a look at T13555#10603383.

This current plan makes Minerva.css a de-facto Mobile.css. The problem with this approach is that it brings a strong mobile/Minerva coupling. It makes Minerva on desktop domain unmanageable (too much code conflicts), and much worse, it closes the door to implementing additional skins on mobile. I think this would be a bad move in the long term.

While doing some code browsing about an unrelated task, I noticed that, in MobileFrontend, some update may be needed in PageHTMLParser.js.

We have gadgets, namely DeluxeHistory.js (which is quite popular) and AddContribNumberInNewPages.js, that on lists such as history pages:

Note that in addition to lists such as history pages, recent changes, new pages, etc., such usernames are also displayed on diff views.

Solved by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1071286

Solved by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/965462

In T68637#10490325, @matmarex wrote:

the tradeoff is that we can't distinguish == … == from <h2>…</h2> (with no attributes)

I don't think we should complicate the hook or any other PHP-related parts. I have already looked into this and suspected such a change would be complicated to implement. It wouldn't be justified for that single use case.

Currently encountering an error during the unit tests, at this line: mw.title.lua#L91.
That is because of an attempt to concatenate the new value nil.

There are many remaining instances of createEvent(), but almost all (if not all) are in embedded libraries.

Uploaded patchset 3. It now accomplishes two things:

• Sets nsText to nil for interwiki links, as pointed out above.
• Adds the missing unit tests, as originally intended.

In order to be able to prepend the item, I was considering to pass $data to the onSkinAddFooterLinks hook, instead of generating a $newItems that is then merged into $data.

Mmmm, it wouldn't work this way, as $newItems is an empty array, that is populated by onSkinAddFooterLinks(), then back in getTemplateDataFooter() is merged to $data (using the foreach).

I can accept your rationale, even though the resulting behavior is very counterintuitive.

It is similar to the usual issue with substed templates, where the inner templates (and parser functions, etc.) have to be substed as well.

I noticed a strange #footer-places-terms-use { float: left; } style in the footer, which has been introduced in gerrit 596492.

Thanks for pointing this out. Good catch 👍

In T148313#10369821, @Pppery wrote:

Jackmcbarn hasn't been active for years so won't respond.