For the record, the message has been implemented in Cologneblue too: https://gerrit.wikimedia.org/r/776234.

However, for this localStorage to be effective, its value should be read on startup, when the script is executed on subsequent page views.

Note it wouldn't fully solve your use case, because my solution wouldn't trigger the API save either. But it would solve the issue on same browser.

That's due to the debounce of the API save. Such a debounce is mandatory, otherwise the user could trigger a lot of API calls. Not to mention that because the HTTP requests don't necessarily finish in the same order they were started, another request than the latest one could end up doing the lastest save.

There was no patch for the REL1_36 branch, is it an overlook?

Thanks for the patch :)

I noticed the (currently abandonned) T257075 that proposed to refactor the checkbox hack, replacing the multiple exported method with a single super object.

Pushed a commit to also optimize some selectors that use the [data-mw="interface"] attribute (refs https://github.com/wikimedia/mediawiki/commit/b1e3f9e38d7c74e080e99e58dac55629b9f0b097).

Although this certainly has been discussed somewhere already, I'd suggest adding classes .mw-diff and .mw-catlinks, that would be used instead of table.diff and .catlinks respectively (of course, keeping these for BC).

The selectors may be optimized:

The best would be to call checkboxHack's setCheckedState() method, and only when it would actually change the sidedar state (e.g. if the sidebar is already collapsed, avoid calling setCheckedState(false)), in order to avoid triggering extraneous "input" events (as it may have unexpected side-effects). And of course, there is still the need to avoid the API save, which may be solved by setting a temporary flag.

Another issue is that the automatic collapse/expand are done by setting the checkbox.checked property, which doesn't trigger the input change event. See in checkboxHack.js for thorough explanations. So we are missing everything that is added/modified using JS event handlers, such as ARIA, and possibly things bound elsewhere. And because of this, the state of these "JS managed" things may become stale, mismatching the actual collapsed/expanded state.

Don't miss the comments by Vlakoff on the Gerrit page, some of them contain important information. Also, don't hesitate to compare between patchsets, as it may help understanding the individual changes.

The code currently used ($( window ).trigger( 'resize' );) works with jQuery event listeners but not with native listeners,
i.e. it would execute a listener attached using $( window ).on( 'resize', … ), but not a listener attached using window.addEventListener( 'resize', … ).

Please have a look at the comments I posted at https://phabricator.wikimedia.org/T300826#8568297.

The code to trigger the window resize event is inside the saveSidebarState() function, which has a 1000 ms debounce when it is called from bindSidebarClickEvent(). Thus, there is an undesirable delay of 1 second before repositioning the elements when the sidebar is toggled. This trigger of a "fake" window resize event should be decoupled from the API save, and executed immediately. This will result in a much snappier interface. And of course, triggering the fake window resize event and saving the state to API are two completely different things, which shouldn't be blended together.

Not sure this ticket is the best place to report, but after searching about "mediainfoview", this talk page archive led me here.

Reminder to self, the strtr() documentation states that « The longest keys will be tried first ».

(deleted the previous post, a stupid confusion between like and rlike)

On the French Wikipedia, we also have .navbox elements, however, they are not <div> but <table> elements.

I just noticed a small defect, present if both the current code and I my suggestion of fixed code:

Just a bunch of tests (and I've done many more, for example with \*, \?…):

"f+oo-bér" like "f+oo-b?r" &

I'm doing some tests, and it seems the fix is as simple as removing the '\\' => '\\\\' from WILDCARD_MAP. (and in turn, the '\+' => '\+', '\-' => '\-', and '\.' => '\.' would become useless and could be removed)

Also, I think the WILDCARD_MAP property should be moved from the AFPData class to the FilterEvaluator class (which is the one who uses it), as a protected property. Case in point, this array is not "general" and is really meant to be used by the keywordLike() method, and is applied on the result of a preg_quote(). Note this property is not used anywhere else (search in the codebase).

Uploaded patchset 4, which takes advantage of the fact that the root getElementSortKey() is executed only on cell elements (i.e. not on <img> tags etc.). It consolidates the code, which was needlessly split, and saves redundant executions of .nodeName.toLowerCase() (from 1 to 0 execution on the root node, and from 2 to 1 execution on (almost) every child node).

Uploaded patchset 3, that uses an inner function. I think it's definitely a better approach.

I'm thinking of a better approach, maybe it would be better to use a dedicated inner function for nested processing, rather than reusing the root getElementSortKey().

Just uploaded this subsequent patch, following up to this comment by @Krinkle.

As a reminder, this comment (Gerrit doesn't send me email notifications).

I would also support adding new keywords and functions. Mainly because of the BC concerns discussed here, and also because it's really a different processing when working with an array: instead of strpos() on bulk data, we are doing in_array() on a list.

If I use data-sort-value="foo bar" in wikicode, the HTML output is data-sort-value="foo bar".

Also, we may want to normalize and remove the consecutive spaces, by adding something like result.replace( /\s+/g, ' ' ).

In this line :

This seems to be a limitation of the underlying MediaWiki Title class, which apparently doesn't support interwikis by design.

As pointed out in these comments, when there is an interwiki, the Scribunto Title objects give some erroneous results, which in turn affects the results of the "talkNsText" feature I was implementing here.

I confirm Chrome and Firefox seem to have implemented some optimization for the $( '#ca-addsection a' ) case, because it's significantly faster than $( 'a' ), otherwise it would have been the contrary.

As I pointed out in this comment (and the following one), there are still some issues on this matter.

Also, I found quite surprising that clicking on another project automatically launch the search.
I think it should rather blank the results (of course keeping the input), and launch the search only when the user clicks on "Search".
Yes, that would mean an additional click, but I think it would be less confusing.

I found a quite major defect in the beta:

The beta version keeps the input in "use case 2", but not in "use case 1".

I think too the thumbnails should link to the article, not to the file page.

Some notes about the implementation:

I'm taking the opportunity to change the event type from "click" to the more modern "change", supported by IE 9+ (refs caniuse, MDN). See patchset 2.

Refs some related commits:

• 2012-01-08 - Clean up
• 2012-01-09 - Provide cleaner handling of action=historysubmit hack
• 2014-06-11 - Simplify checkboxes script on History pages
• 2022-02-15 - ReverseChronologicalPager pages have list headers grouping by date - See https://phabricator.wikimedia.org/T298638

I have updated the list of IDs and classes in the documentation: edits 5499359, 5499361, and 5499362.

You can try it on our home page using the following code:

I agree too that this move of the language switcher to the bottom of the page, because there is no other place for now, as a "let's hide this under the carpet for the time being" workaround, is really ugly!
Of course, everyone is already aware of this and agree that this definitely has to be improved. Especially as we are dealing with the home pages here.

hlists inside warningboxes should not have a left margin, nor should they be crammed together.

Patch submitted. The lack of "direct child" restriction definitely seems to be an overlook.

What is the purpose of the following code in mediawiki.hlist/default.less?

Ah, of course, because if using the wiki with English language, the displayed message is not MediaWiki:Previewnote, but MediaWiki:Previewnote/en... Please try with the default French language.

Use case: System message MediaWiki:Previewnote on French wiki.

I just noticed the bug too, and was about to open a task suggesting to use more specific, direct child, selectors (i.e. .mw-message-box > :only-child).
Preliminary diggings led me to https://phabricator.wikimedia.org/rMW1fd66a67edcd, then to this already existing task.

@Krinkle May I kindly ask if you have news about this?

You can test the mobile version on a desktop computer simply by using the fr.m.wikipedia.org domain. Although not on a smartphone, it's sufficient when writing local CSS etc.

Uploaded a new patch:

Here is the CSS I'm adding in the patch:

.mw-special-Mostlinkedtemplates .mw-redirect {
    font-style: italic;
}

A few notes:

• I'm precisely targetting Special:Mostlinkedtemplates (for now), but maybe we want to italicise redirects on other pages as well.
• Notice this CSS is loaded on all special pages (see rMW15eac4c27939).

Redirects should be italicised on this special page as well: Special:MostTranscludedPages.

It is registered as a different module

Understood. It loads vector.js (from the legacy skin) in addition to the rest.

Thanks @Func for looking into this.

Indeed, I was also encountering this issue on mediawiki.org. I don't remember on what pages exactly, but I'm pretty sure it was occurring on ResourceLoader/Core modules.

Also, I usually fix this issue by doing a force refresh (shift + F5). A regular refresh (F5) isn't sufficient.

I am also encountering this issue. Nowadays it seems less frequent, but it may still happen sometimes. (edit: a fix has just been deployed, it simply hasn't reached frwiki yet)

I just noticed the .mw-first-heading is missing here:
https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/475508647466ea1c67d3e0d378ca3b4a76668e84/stories/skin.stories.data.js#91

Following up to gerrit 737112 from late 2021 which has these FIXME:

Currently all skins have #firstHeading, .firstHeading and .mw-first-heading, the only exception being cologneblue which only has #firstHeading.

1. Back in 2009, class .firstHeading had been replaced with an ID #firstHeading, see T17427 and https://phabricator.wikimedia.org/rMWc68f345d54c3
2. Very soon after, the class .firstHeading has been restored, alongside the ID, for backward compatibility, see https://phabricator.wikimedia.org/rMWba0f7c4c1378
3. In 2014, the ID has been considered obsolete, see https://phabricator.wikimedia.org/rMW7d244175a3bd359bd and also this documentation update.
4. The present ticket introduced a new class .mw-first-heading for name standardization.

Currently the font has a pixel-based size (gerrit 593629).

Here is an extract of the markup in History and User contributions pages:

Has been fixed on Gerrit (relevant occurrences of class replaced with link-class).

Tests currently fail because user-links-collapsible-item is added to the <li>, and mw-ui-icon mw-ui-icon-before are added to the inner <a>,
but the tests look at the same place for both sets of classes: $content['user-menu']['userpage']['class'].

Some people may prefer to keep this additional item in the dropdown menu:

• Has a text description.
• The "Contributions" link is next to it.