In T367103#9877618, @Jdlrobson wrote:

According to @Catrope the problem here is "MW is stuck on a PHP port of an older version unfortunately".

In T204201#9873811, @SD0001 wrote:

If you mean during preview, yes it will load if the last saved revision of the page had the category wikicode. What section you're editing is irrelevant.

Another issue: I have a case with a gadget that is defined with a "category" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using(), on pages that do not have the category.

You made the confusion that I was fearing: in the current code, there is no calc(), only a bare addition (resulting from some Less transclusion), which is invalid CSS.

That being said, we should avoid such dynamic client-side calc() here, as beforehand server-side, we are able to determinate the plain value.

Note that calc() works in media queries, although it is not valid according to the formal definition. See this thread on Stack Overflow (for instance this answer, which points to the specs and to the browser compatibility table).

Alternatively, could also a "negative mode" be implemented?

In T331227#9861692, @XanonymusX wrote:

Side note regarding navbox layout on mobile: on dewiki, the navbox is already responsive, see eg Navbox Madonna. In case further inspiration is needed …

Similarly, if the action if a history view, will the page categories be known?

About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?

On a related note, could these breakpoint values be offered as CSS variables, just like we already have CSS variables for colors (e.g. --background-color-base)?

I noticed an issue with this change, because these descriptions are also used elsewhere:

If it input for instance   in wikicode, this entity is supported.

By the way, thank you for looking into this, and my apologies for the confusion.

I have understood. It is because I am using a personal script to convert the "Compare selected revisions" button to a link (so that it is middle-clickable), and it is this script who was adding the type=revision parameter (see here).

From a history page, I was used to get the following URLs:

• for a single revision diff (the "link" links): &diff=prev&oldid=42
• for a multiple revisions diff (the "Compare selected revisions"button): &diff=42&oldid=39

The commit message gives the example 2^53 == 2^53 + 1 that erroneously returns true, but it is because of the 2^53 + 1 expression, which for sure is exceeding.

FYI, I have just added support for the new markup in this gadget on frwiki: https://fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-AncreTitres.js&type=revision&diff=215319381&oldid=213586059

In T331679#9805631, @Jdlrobson wrote:

• This will result in user scripts loading after site scripts again (as a consequence of alphabetical ordering)

Just asking out of curiosity, how did you manage to find this limitation?

In T357199#9788592, @Theknightwho wrote:

I couldn't replicate this in ZeroBrane - the difference was essentially negligible, but slightly favouring the version which contained local getmetatable = getmetatable.

So the mw.site.* calls would be more expensive, but the improved bootstrap time would largely compensate for it. That's another interesting idea.

There are two issues discussed here, I'll try to answer about them separately.

The problem is that the topmost known element is config.$previewNode, which is the #wikiPreview element (unless configured somehow else, but I'm not aware of any occurrence of such tweak).

MediaWiki code searches:

By the way, I just noticed that when running mw.hook('wikipage.content').add($content => ...) in the visual editor, the $content element is completely unrelated to the page content, see File:Hook_param_$content_in_visual_editor.png.

This issue dates back to T35399.

You may want to have a look at T349298.

I have just encountered an issue in a gadget because of this discrepancy: https://fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-Accessibility.js&diff=prev&oldid=212995332

Related, with classic Vector skin: T358545

As the functionality was new, in 99.999% of existing uses there was no replacement to do actually. Thus, I wanted to optimize these cases the most possible, and the plaintext string.find() is a prefilter to rule them out as fast as possible.

While doing some random test, I noticed the 4 assignments local getmetatable = getmetatable, etc. actually make the code slower.
What makes the code slower is not the assignment, but the access to the local variable instead of the global function. It's as if the Lua engine had some internal optimization for these global accesses.

Agree too for always showing the links.

The code is very misleading:

// Patrol link is hidden when no preview shows, unless the user has specifically
// opted out of previews via user preference (T357693).
$showPatrolLink = $userRequestedDiffOnly ? false : $diffOnly;

(then, $showPatrolLink gets passed as argument to the markPatrolledLink() method, as the $isDiffOnly parameter)

One caveat I thought of with enclosing styled bare <h2>'s with the mw-heading <div>, is that it would prevent margin collapsing with the preceding (or following) element.

Removal of the "old" and "hybrid" markups will definitely improve the situation. I would have preferred to no longer see the "plain" markup too, but if converting an input such as <h2 style="color:orange; margin-top:2em;"> to "new markup", as the color isn't inherited, it would have to be directly applied to the inner <h2>, and the the margin-top would preferably have to be applied to the outer <div class="mw-heading">… of course, it is not feasible to implement handling for each and every property…

The last 2 linked searches above are mistaken: user pages shouldn't be named Vector.js/css, but vector.js/css (contrarily to the site scripts, which are Titlecased). Just change "Vector" to "vector" in the last 2 links.

It's not about Common vs Vector vs Vector-2022 etc scripts. It's about ensuring user scripts (whether common, vector, etc.) are loaded after site scripts (whether common, vector, etc.)

(off-topic: I'm really sorry to hear that fr.wikipedia is still amongst the most error-throwing wikis. I had a look for requesting Logstash access, but that sounds just a bit too cumbersome to me. Though, would it be possible to provide me some information to spot the most problematic codes, without breaking the NDA?)

• The global lookups to getmetatable, etc. functions are cached so the (numerous) recursiveClone() calls avoid them. Considering the gigantic number of recursiveClone() calls, that's certainly the biggest optimization of your new variant.
• And by using the do...end block, mw.clone() calls (and they add up, at least one per {{#invoke}}) benefit from this lookup cache as well (instead of creating a new set of caching variables every time).
• Nice one too with the scope of tableRefs (refs The Implementation of Lua 5.0 [PDF] - Sections 5: Function and Closures)

So there is some room for improvement, thank you for investigating this.

I feel that the only thing that blocks the switch to ES8 is that async is not yet fully supported in the minifier (per T277675).

Please, please keep the requiresES6 flag at least until ES8 can be used in scripts. On frwiki, we have scripts that use async/await, and this language feature makes the codes incredibly simpler. We even had codes with the ?. operator, but I rewrote them to avoid using this operator (for now). But the async/await is a must have.

I confirm that having these many markups, that overlap, makes it a headache to create selectors that pick the desired elements, and only these.

Another thing, here's the new markup I currently see on the pages:

Hi, on frwiki homepage (permalink), I noticed there is an element in the wikicode that doesn't get converted to the new markup: <h2 style="margin-top:1.5rem">. When removing the style="margin-top:1.5rem", the element gets converted, as the other <h2>'s of the page.

Related: T259211

Just to confirm: the wgTitle JavaScript config value is completely unrelated, and there is no plan to deprecate it ever, right?

Arguably, filter IDs could be considered as their "name". For instance, on frwiki we often refer to the filters just by their numbers.

I have just encountered this issue. A gadget migrated its options schema, and there are a bunch of old items to clean up. Currently, the best I can do is to set these to empty values, so that at least it takes little space.

@matej_suchanek I took the liberty of subscribing you here, as I mainly comment on Phabricator :)

Alternatively, we may play it safe for now: keep filter IDs num-formatted, and just cherry-pick the 2 changes for log entry IDs (see in SpecialAbuseLog.php).

Uploaded patchset 3, which takes care of occurrences of formatNum() that were remaining.

By the way, Flow has a dedicated AbuseFilter group. See the wgFlowAbuseFilterGroup variable at Extension:StructuredDiscussions#Configuration.

It's perfect just like this, thank you!

If it is feasible, I guess it would be nice to support the same markup as {{DISPLAYTITLE}} does? i.e. '', ''', <abbr>, <sup>…

Change 960131 introduced a regression on frwiki, see our localized message MediaWiki:Abusefilter-history, which makes use of template {{n°}}.

As I was working on these changes, more and more race conditions were emerging… You can see in the changes history how it went horribly.
(and actually, there is at least one other issue remaining, that I had fixed locally, but lacked the motivation to commit.)

Sure, you may cherry-pick this change if you want to merge it yourself :)

Any news on this? I would really love to migrate the filters on frwiki from page_age to page_id, which would save a few milliseconds on every page edit :-)

@Frostly I have submitted a patch for this, but feel free to work on this too if you want to learn the tools :)

By the way, a search for max-width: @width-breakpoint in the codebase (search results) reveals a lot of other mistakes.

Yes I am aware of these @max/min-width-breakpoint- variables. These are of course a better option, as they remove any risk of mistake.

There are still a lot of inconsistencies in the codebase, as the layout changes are defined sometimes before the breakpoint, sometimes after. Therefore, when the window width hits exactly the breakpoint we encounter a "mixed" state.

Also, when editing a page of the Module: namespace, there is no "Show preview" button. Thus, to be able to preview the edit summary, one had to copy/paste it to another edit page…

A code such as:

By the way, for the batchSize we could leverage the high API limit. Something like:

The comments by Nardog are relevant as well. This regression appears to be more and more frustrating for me… so I am forced to disable live preview for now.