Thanks for documenting so well. Yep, I suppose the collapsing block is involved. I'll include this in my checklist before I come up with the (long-in-the-works) new release.

Could you include some method to prevent the addition of the drag bar and setting height?

Thank you, that's due to T415958. The hotfix is now live.

Please consider the grand scheme of things above ad hoc considerations like whether some scripts will break. I don't have an opinion on this one, but I've witnessed not once and not twice how people introduce complexity to things that don't really need it but end up suffering from it, being carried away by these ad hoc considerations. The prototypical example perhaps being ECMAScript having methods .includes() and .contains() for different types even though they have the same semantics just because there was a framework that employed the bad practice of modifying the prototype of strings and arrays. That framework is long dead but the inconsistency is now with us forever.

come on guys do something it's 2025. I RESENT this having the low priority, because the accumulated harm of this across all the users over all the years is substantial

Existing English Wikipedia to-do list user scripts:

• User:SD0001/W-Ping, mentioned in the task description
• User:Evad37/ToDoLister
• User:BrandonXLF/TodoList, stored in user options
• User:קיפודנחש/pageCollector

Research established solutions for to-do lists and pick up ideas maybe? E.g. start with Todoist. Also think of integrations with other MediaWiki workflows, APIs, and tools so that to-do lists are more than simple lists and can leverage all mentioned to give rise to emergent capabilities.

Thanks for the task. I'll add a full configuration for zhwiki when I get a free minute :)

Hey @ShahZamanPathan! Thanks a lot for the translation. Deploying new translations has been temporarily put on hold for the reason that—what is currently translated is messages for the new version of Convenient Discussions which will be released soon. Deploying it right now would lead to several conflicts which the users have reported.

Lol, checked the current standings in the Formula One 2025 season and was sure that Norris won it ...before realizing there is a horizontal scrollbar

This one I overlooked, big thanks! It's live.

@Bhsd Here you go. It's of https://en.wikipedia.org/wiki/WP:Sandbox?action=edit&safemode=1.

In T405063#11197461, @Bhsd wrote:

I cannot reproduce the issue for the standard editor. In that case, although there are two .imeselector.imeselector-toggle elements, the other one is for #wpTextbox1 and is always display: none when CodeMirror is on.

🤔 I can reproduce with &safemode=1 in both Chrome and Firefox.

And one more note: If you prefer to stop short of supporting syncing between instances, I'd still argue for effort to be made to decouple instances from each other, even if that requires decoupling hooks and such. Like with the characteristic example of conflicting HTML element IDs, it's just favored practice to allow things to work in isolation from each other. With all due respect, "Support for having multiple instances of a class" (not a singleton!) shouldn't be a thing; that should be a default. (Unlike "Support for having instances synced".)

In T404117#11171015, @Jack_who_built_the_house wrote:

Your mileage may vary, but I think it's conceptually OK to have the preference set by the last action as the source of truth.

E.g. on the web, you may change preferences in one tab, while old tabs of the same website may stay with old preferences. So unless you refresh the pages, they will stay outdated. The old tabs are neither invalidated nor synced due to the fact that the value in source of truth has been updated. Mechanisms to counter this are costly and rarely developed. That's the way I see it at least...

In T404117#11170447, @MusikAnimal wrote:

It sounds you like just want to be able to toggle CM on child instances independently of the primary instance? If that's the case, we're probably only a few tweaks from making that doable in the CodeMirrorChild class via a fluent config setter method or something. It still feels wrong to me, though.

It feels wrong to me too for several reasons:

1. Conceptually, comment form instances in Convenient Discussions are not related by parent–child relations. They are peers.
2. CodeMirrorChild is not a mixin; it extends CodeMirror and not CodeMirrorWikiEditor. I work with CodeMirrorWikiEditor, so there would be an overhead if I used CodeMirrorChild and ditched CodeMirrorWikiEditor (duplicated code, upstream desync issues, etc.).
3. Currently when I disable syntax highlighting on a child instance, it isn't disabled on the parent instance – only the other way around. (Which makes sense for parent–child relations, but see item 1.)
4. Jumping to another instance when trying to change preferences in one instance is strange UI.

Will be fixed by r1186187.

Oh great, you guys are quicker than me.

In T403995#11160888, @MusikAnimal wrote:

I'll note that for what you're trying to do, you may (or may not) want to use CodeMirrorChild instances.

@Tacsipacsi, @DLynch: Thanks for directing me. Yeah, I care about non-WMF wikis as well. I guess checking for 1.43 would be enough.

But then:

I think the only condition for the API itself to be available is that Thanks is loaded

– if the version of DiscussionTools is older, it's not available. Should I check that mw.config.get('wgVersion') is not lower than 1.45.0-wmf.15?

@Tacsipacsi I think you mean the API of Thanks itself, but I implied that DiscussionTools' thanking API built on top of it. It allows requests like this:

{
	"action": "discussiontoolsthank",
	"format": "json",
	"formatversion": "2",
	"uselang": "en",
	"page": "User_talk:JWBTH",
	"commentid": "c-JWBTH-20241120024200-JWBTH-20241120024100",
}

Great job developing the feature!

(Subjective also) I simultaneously subscribe to the idea that content is what matters most, but also can't help but notice that in the absence of a design solution to integrate wide elements, be it tables or graphs or images, in the existing layout, just keeping the tables overflow the content area is suboptimal. Moreover, on @Quiddity's screenshot, the table is still limited by the left column, with TOC. If the goal is to allow the table occupy as much width as the viewport allows, then why agree to such a half-measure? I would suggest to allow to expand tables to fullscreen just as you can expand images.

For example, my gadget can already display diffs and revisions from linked interwikis, but only in controlled spaces like Wikidata edits in the watchlist, global watchlist and global user contributions. I want to expand these actions for all links, including user-contributed content, but I don't have a list of servers where these requests will work reliably.

Please provide a public API if it's not available already so that tools like Convenient-Discussions could hook up.
Update: Created T405008: Provide a flexible public API for UserInfoCard.

(This was solved quickly, thanks.)

But I'd also be very concerned about not trying to reinvent the wheel here, especially in the light of your rightful comments about the size of the team of Wikimedia compared to Google's. So, this remark got my attention as well:

We aren't aware of anything like a plug-n-play option that would "just work" on-wiki.

@TJones Thanks for taking the time and sharing your perspective in such detail. Thank you for the task links as well. I subscribed to them all.

But, by the way, there will be a bit of inconsistency now that headings like h4 will have a margin while definition list terms (;) will not. This may confuse the users.

In T384777#10939653, @matmarex wrote:

I agree that the 75px is weird, but note that after my changes, it will be only applied when linking to a section header. The link target in your example will be aligned with the top of the page, just like the reference backlink targets.

@matmarex Thanks, this improves the situation, albeit partially. I have some general criticism about how in-page links work (I believe this 75px scroll intersection threshold is flawed, especially the fact that it's bound to how section links behave – e.g. go to https://en.wiktionary.org/wiki/Appendix:Glossary and click the link in "See second person."), but that's a separate big conversation.

In T303612#10930718, @stjn wrote:

Currently mw.notification-style popups are a bit of a minefield: you can have links in them, but you have to be very careful to click on them and not on the surrounding space, because that closes the notification. Ultimately, this is very inaccessible, especially if someone has motor issues.

Yeah, aiming links in toasts is a constant headache. See also T316425: multiline links made things even worse (although, as I understand, the toasts will now be wider, so multiline links will be less common?).

Yeah, I mean, it's likely trivial, but you need to nudge people in the right direction, provided that tool maintainers are overwhelmingly not front-end people, I think, but a lot of tools could benefit from utilising a design system and components shared across the Wikimedia ecosystem, especially if they're simple to use and well-documented.

This task is about using Codex in gadgets and user scripts. How about the use on Toolforge?

(Email notifications are part of Echo I believe?)

@thiemowmde Nope, it fixes the annoying UI in an obvious way (but is outdated after 12 years?). The problem is that this may not be the optimal solution; see T68965#10893232.

This is annoying and doesn't make sense: a setting regarding how notifications behave is not on "Notifications" page.

In T299772#10853462, @Jdlrobson-WMF wrote:

• Could it not run on both skins and update the href of #ca-edit to point to the full article (e.g. drop section=0)? I feel like a gadget that results in a consistent experience on the skin seems better, no? I am guessing this is working around T2156: Allow editing the lead section of a page and T196915: Give mobile editor a way to edit more than just a single section at once

Note: there is an "Edit full page" link in the Minerva menu so this might not even be needed on this skin? Maybe @DLynch has thoughts around this.

In T299772#10852858, @Jdlrobson-WMF wrote:

Why can't you use mw.config.get('skin') for your use case? What specifically are you trying to detect?

Two things:

@Jdlrobson-WMF Thanks for researching this. The funny thing is that the only occurrence of mw-mf in global code says this:

	// TODO: Replace this with whatever config variable is decided on in
	//  https://phabricator.wikimedia.org/T299772.
	//
	// This used to be determined by checking whether <body> had the "mw-mf" class. However, this
	// was determined to be a non-trivial read from the DOM and one that could cause a forced style
	// recalculation in certain situations.
	//
	// See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/799353/1#message-21b63aebf69dc330933ef27deb11279b226656b8
	// for a detailed explanation.
	const isMobileFrontendActive = c( 'wgMFMode' ) !== null;

In T395079#10851090, @Jdlrobson wrote:

That is because it is not to be considered stable. Please do not use it on wiki. We only document stable code.

For mobile the mw- prefixed class is better covered by https://m.mediawiki.org/wiki/Stable_interface_policy/Frontend

Nobody seems to care about this, yet in my belief this is one of the crucial points why people (e.g. me) would regularly use Google to search Wikipedia instead of Wikipedia itself.

In T374214#10781987, @Tacsipacsi wrote:

There’s T373769: Rework "Page version status" in FlaggedRevs to be unambiguous about its nature, there’s T379085: Latest accepted revision popup sometimes doesn't close, I don’t think we need a third open task about the same problem. (I 100% agree that the current behavior is bad. But there are better places to keep track of this.)

Still, if you hover over "Checked" while moving the mouse up (e.g. at https://en.wikipedia.org/wiki/Pop-Tarts), the popup doesn't disappear until you hover it again and unhover another way.

In T361737#9915929, @Jack_who_built_the_house wrote:

How about a gradient to transparency so that it is clear that the element continues to the right?

tools (at least Convenient-Discussions; DiscussionTools AFAIK produces such incorrect behavior) in such situations place the reply directly above the branch with outdents -- which breaks the chronological (and logical) order and is quite an ugly hack by itself, but the lesser evil here

Here's a demonstration of what DT does and what CD does (I already linked it in my comment above). Your description is almost correct except that DT inserts the reply above the {{outdent}}.