Seems to be working.

I think this is basically the same as the newer T427093: TypeError: can't access property "parentNode", startMarker is null /.

In T197137#12107394, @Soda wrote:

Yes, defacements do occur through template editing; my understanding is that it is not the primary threat vector for Common.css, but rather the ability to deanonymize users by harvesting "CU-grade" information of every reader and logged-in editor who visits the site.

The bar for suppressing native, expected browser behavior is high. There is a tendency among devs to put it significantly lower, and I see the worry that visited styling "adds extra visual variation to a list that is meant to stay stable and easy to scan" as a manifestation of exactly this tendency.

Alright, added a full-fledged template parser. Templates having nested templates are now handled as well.

The reason is T422291: Wrong section edit link target with Parsoid when section is transcluded. It says it was resolved a few days ago, so we will have to wait.

In 99.99% of cases, the text wrapped into an element together with a user link is part of signature. But I agree that a false positive here is very harmful and should be addressed.

I appreciate SpecialPages not looking like AI pages now (knowing it was designed before the AI trend, of course)

In T429071#12021592, @Jdlrobson-WMF wrote:

Is this a duplicate of T195935: Article Preview Popups trigger on keypress when link is ctrlclicked ?

A light fix so far — templates with no nested templates are now cloaked when searching for section heading markup. Just "templates with no nested templates", as doing full parsing would be somewhat costly. And rarely sections can really be wrapped in templates. I can add logic for those cases but won't until it proves to be a real use case.

I updated comment links with IDs containing # to use Special:FindComment with idorname parameter, as with T426732: DiscussionTools produces invalid fragments for topic titles with curly brackets (or other non-wgLegalTitleChars?).

(I implemented the proposed behavior in CD, since I'm less influenced by the completeness constraint compared to the official thing, but if there are practical examples of editable comment blocks transcluded to uneditable pages when these blocks AREN'T transcluded together with a section heading (in those, CD shows Reply buttons), I can reconsider.)

@HakanIST

Some follow-up: CD is one trigger (ruwiki)

Still getting them from CD? Same error text and call stack?

I implemented 2 so far. Please tell after a while whether errors persist or not.

DT's markup is complicating things for CD's parser and 5 years ago, when I wrote this part, I likely assumed that that markup is not involved in scripting when Reply Tool (which CD officially conflicts with) is disabled and went ahead to remove it. And probably it wasn't involved until newer features were rolled out including "Visual enhancements". Now that it is involved and causing errors in DT, I'll have to rethink this.

Yeah, that's what I meant.

Thanks for pointing to errors in how CD handles this.

(Please give me a shout if anything will need to be changed in Convenient Discussions as well)

@1F616EMO Yeah, this could work.

@1F616EMO The problem here is that that template has the mw-archivedtalk class. As a result, CD treats it as a container for an archived discussion. Without this class, the parsing will be correct. If you want to disable the reply button in both DT and CD for this element, add the mw-notalk class instead.

Thanks. This appears to have been fixed.

@1F616EMO Sorry, I'm being silly. There is no Element in the worker scope (and if it were, it'd be domhandler's Element), so you get "ReferenceError: Element is not defined" errors. You'll need to check for 'matches' in node instead of node instanceof Element.

Great compromise.

@1F616EMO In the worker context, node is domhandler's Element with some props and methods I added for uniformity. It doesn't have the matches method. innerText and nodeName I've just added as aliases for textContent and tagName.

Excuse me, how does that work? If for whatever reason this resubmission is unaviodable but deterministic, why not resubmit programmatically and only prompt the user action when the challenge is ready?

I definitely need a better doc here, haha.

Captcha works now, including the new one (see T424598: Update ConvenientDiscussions to use mw.libs.confirmEdit.CaptchaWidget instead of mw.libs.confirmEdit.CaptchaInputWidget).

So, as I see from your commit to DT, mw.libs.confirmEdit.CaptchaWidget works quite a bit differently from mw.libs.confirmEdit.CaptchaInputWidget,

1. requiring separate updating and rendering steps (with mw.libs.confirmEdit.CaptchaInputWidget, calling the constructor was enough);
2. requiring the container to be added to the DOM before the captcha is rendered (whereas mw.libs.confirmEdit.CaptchaInputWidget, on the contrary, supplied you with an element to add to the DOM).

@Dreamy_Jazz I need to support old MediaWiki versions. How will I be able to detect whether mw.libs.confirmEdit.CaptchaWidget is functional already? Or testing for 'CaptchaWidget' in mw.libs.confirmEdit is enough?

In T422073#11908310, @Tacsipacsi wrote:

On the other hand, there are noticeboards where the higher-level sections are <h2>s and individual topics are <h3>s, so the <h3>s should be sorted on them.

An open question: What to do you if there are <h1>s on the page? Sort inside them, don't sort? Sort <h1>s themselves?

So where will the control reside, where will the user preference be? I imagine it will be the kind of preference that you might want to change often and depending on context (the page). Do you see it the same way or differently?

And you need 3 clicks to get to the full preferences. The first challenge is to find CodeMirror preferences at all, the second is to find the full preferences.

editors would definitely benefit from having easier access to copying wikitext link syntax.

@matmarex Is it possible to enforce length limit with your solution (which was one of the reasons to move to separate inputs, based on Ppperry's link)?

I oppose the status quo and oppose any solutions where there is no way to have the full pagename in a single input. @matmarex's solution is quite sound and definitely better than the status quo. The warning just tries to explain away a bad status quo, just like the preview is a superstructure over it.

Site note: If you go with the overflow menu, please make the blocked state of users available anywhere in the JS interface so that other tools (like markblocked gadgets or my Convenient Discussions) could pick that up and reuse it. API requests to get the blocked state are very expensive, especially on pages with hundreds of posters, which is why Convenient Discussions currently only marks temporary accounts with their UserInfoCard icon whereas blocked users keep the usual icon unless the markblocked gadget is also used.

I had an ambition to make Convenient-Discussions (repo) type-safe and undertook a large-scale rewrite. But instead of just rewriting in TypeScript, I rewrote it in pure JS + TypeScript-flavored JSDoc in an attempt to somewhat bridge the gap between the modern web dev and what we have in MediaWiki user scripts, and see what's possible these days.

In T423949#11859503, @kostajh wrote:

We would want this to display next to usernames, like it does elsewhere.

(How do you plan to display it next to usernames given that signatures are free-form and the username is not guaranteed to be there, may have arbitrary appearance, etc.?)

I don't know if this is relevant here, but Convenient-Discussions has an "Improve performance" setting where it hides bottom sections on long talk pages to mitigate rerenders. To not interfere with Ctrl+F, it does the simplest thing — unhides them on window's blur event which is emitted on Ctrl+F along with other occasions. The reason for hiding them is irrelevant while the window is not focused anyway.

I earlier wrote a piece in https://www.mediawiki.org/wiki/Gadget_kitchen#Running_code_on_page_load mentioning this misconception:

• Be cautious about what comes in the $content argument of the handler function. You shouldn't assume it's the #mw-content-text element. It can be a small portion of the page, e.g. when it is previewed.

Note: people unfortunately do get confused by this shorter syntax {{plural:$2|{{gender:$4|$3}}}} as well—in this case, the translator moved $3 inside the curly braces, but only for the last parameter :(

In T423525#11836271, @Tacsipacsi wrote:

if you fear people won’t understand how {{PLURAL}} works in their language (in a lot of languages, it works such that anything more than one is categorized “many”, but Slavic languages indeed tend to be more complex)

If Russian needs it, I guess other Slavic languages (e.g. Ukrainian) are also likely to need it.

Sure. I've translated into Ukrainian.

@Tacsipacsi Thanks for your guidance.

Thanks for filing this.

@BraunOBruno Yep, you're spot on (even though that's a MediaWiki quirk). Fixed as well.

Thanks for the report. I fixed it. (The cause was parentheses in namespace names which I was unwise enough to not escape for regex matching.)

(Also reported here.)

Fixed.

@ScrubbedFalcon I can't reproduce this. Can you confirm CD doesn't load there? It loads for me.

Wait a sec. Just running mw.loader.load('ext.CodeMirror.v6.WikiEditor') on any edit page yields the same effect.

Thanks for the report. Fixed.

(See https://commons.wikimedia.org/wiki/User_talk:Jack_who_built_the_house/Convenient_Discussions#Support_zhwiki_DYKN — we need a configuration file in the MediaWiki namespace of zhwiki.)

The Pashto translation is live!

Fixed, thanks.

Wow, have never seen anything like this 😂 This is most likely due to hidden="until-found" feature of collapsible boxes. I implemented its support in my updated version and don't see the bug in it. I will soon release it to the public.