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.

I really don't see the point of purposedly hiding the preview of the edit summary, where technically nothing prevents us from showing it.

It seems to be a regression from T293930 (see the code changes).

My mistake: the preview of the edit summary is missing when doing a "Show changes" action. When doing a "Show preview" action, it is present as expected. I have corrected the first message.

Of course strong support for fixing this.

You could make use of #iferror for your case. It catches any element (namely strong, span, p, div) that has a class "error". This includes errors generated by Scribunto.

In commit message of patchset 5, added a note about the addition of \v to the characters trimmed by default.

Added author and source in commit message of patchset 4. I can't say for the license. There is just none.

In patchset 3, I'm replacing s:match( ... ) with string.match( s, ... ).

In patchset 2, I'm replacing the default charset '\t\r\n\f ' with %s. This allows for a much simpler code.

By using margin-inline-start, I managed to considerably reduce the amount of CSS needed, see on French Wikipédia.

Interestingly, the error happens only when "Highlight All" is toggled on, in the browser search bar.

I can reproduce too:

Indeed, the results are a bit inconsistent currently…

+1 for this. Working with the API to inspect past hits, I often encounter the following warning, even with very low limits (less than 50):

The patch should be ready to merge :)

On a related note, in our toolbox we have a « &nbsp; » link, to insert the "&nbsp;" string.

Thanks for merging this old patch.