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.

Sorry, I had forgotten about that ticket T148313 (from 2016!).

(2024 here, coming from the duplicate T381224)

Thanks @Pppery for taking care of this.

I just noticed something surprising, and it's making me ponder. 🤔

I would suggest to be bold, and complete/correct gerrit 983410 by adding nsText to the list of properties that are set to nil. Considering how interwiki links are such a special case, I can't think of situations where this nsText change would break something.

Tests are still failing, and it's quite interesting.

Nope, everything has been taken care of here.

The patch will have to be rebased after gerrit 1092899 is merged.

Fixed tests: gerrit 1092899/1..2.

On a related note, in TitleLibraryTests.lua there are tests for subjectNsText, and for talkNsText as well (T180911), but there are no tests for nsText.

On a related note, in TitleLibraryTests.lua there are tests for subjectNsText, and now for talkNsText as well, but there are no tests for nsText.

The patch currently fails tests.

Note that although the patch passes the tests, gerrit 1083587 (T378314) has been rebased on it but still encounter errors.

Looking back at this ticket:

Refs T179638, which is a more general application of the same principle (filtering properties to avoid loading the whole entity).

Refs T179638, which is a more general application of the same principle (filtering properties to avoid loading the whole entity).

It's been over a year and a half, and these JavaScript errors are still occurring…

Another track for improvement would be to implement some lazy-loading. It is a shame to clone everything when we only use a fraction of the available librairies.

In addition to the "using mediawiki.page.ready" (code search, main code), we might add a mw.hook('wikipage.content').add() (with necessary checks to avoid adding the portlet several times, e.g. in live previews), so that it is executed after the hook from toggleAllCollapsibles.

See T378577 and gerrit 1084722.

Indeed, calc() is available for more than a decade.

Sorry, adding the mentioned user as a subscriber was automatic and unintentional.

In T130824#10264047, @Od1n wrote:

Would it be possible to cover this with a unit test, to help prevent regressions like the one that happened in T378132?

When this Android version from the Roman era is dropped and MouseEvent becomes always available, here is a nice legacy event to clean up: ext.RevisionSlider.util.js#16. Note how much code duplication we have here.

About the other event, MouseEvent, we are supposed to support WebView on Android 5+, that dates back to 2014 (!).

The #wpFilterDeleted and #wpFilterDeletedLabel elements are created (amongst the other ones) in this loop: AbuseFilterViewEdit.php#456.

Actually, the #wpFilterDeletedLabel element does exist. Otherwise, the infuse would produce a JavaScript error.

The "Switch editor" button is created here: AceEditBoxBuilder.php#65.