Not sure what still needs to be done about this technically. The deprecation of the old module can be done by volunteers on wiki.

FWIW AWB also adds /* top */ if only the lead section was modified.

https://en.wikipedia.org/wiki/Example?useskin=vector-2022#top goes to the absolute top of the page since there is no such anchor on the page. The html does not say id="top" anywhere so #top is ignored.

It's not ignored. If you focus the address bar and press Enter/Return it scrolls to the top of the page. That doesn't happen with #foo or whatever.

summary=/*%20top%20*/ prefills the edit summary with "/* top */ " which makes a link like https://en.wikipedia.org/wiki/Example#top to an anchor called "top". This anchor is near the top of the page in Vector Legacy but is not present in Vector 2022.
Compare https://en.wikipedia.org/wiki/Example?useskin=vector#top
and https://en.wikipedia.org/wiki/Example?useskin=vector-2022#top

But a link to #top scrolls to the top of the page, even if there's no element with the anchor/ID top, which is a legacy/non-standardized browser feature. The default signature links to #top when inserted on your own user talk page (presumably to avoid the selflink bolding).

Ace supports i18n since v1.20.0 (and improved in the just released v1.33.0) so we can just propagate wgUserLanguage to Ace when CodeEditor sets it up, though the translations need to be submitted and merged into Ace first, of course, and propagating the fallback chain can be a challenge (another option is to build it into CodeEditor and make it translatable via TranslateWiki). (And I wonder if it works with RTL...)

If we enable it only for the notification button, then we still have the problem of what to do for the normal button when non-live preview is enabled.

I don't understand how this is a problem at all. We can just leave the normal preview/diff buttons alone (i.e. no handler attached).

Does the patch cover T354186: Don't show the edit recovery popup on non-live preview, edit summary prompt, etc.?

@Esanders The patch does not seem to address the problem, which is not that the icons are missing but that these toggles appear at all.

Related: T353998: Allow scripts to pause/"restart" EditRecovery

What about Editing-team? GlobalCssJs may have no maintainer but preview certainly does, no?

Thank you! The link in addCSS() is still broken, but I assume cross-references just haven't been got around to.

In T358391#9613651, @apaskulin wrote:

https://doc.wikimedia.org/mediawiki-core/master/js/mw.loader.html#.addStyleTag

Would a site-wide preference similar to how we do night mode / font size be more appropriate for this and save the user from having to click the link (and it not persisting on each page load).

Do the functions even need to be documented? They're anonymous functions inside a public method after all. (But also: do they need to be initialized from scratch on every call?)

The stability of this method is ambiguous as in the code it hasn't been marked as @stable or @private (it hasn't even been documented).

It was documented until you removed it in rMW9f2e4faea3ff. Before that, it was explicitly non-private, as evident by comparing it to the other "add..." methods under mw.loader.

@Jdlrobson Can you make the files (screenshots?) public?

Wow, you can do that? If you could mark as private what was marked as stable (and thus make it possible to make breaking changes to it without going through the deprecation process), wouldn't that provide a loophole to the stable interface policy?

Nvm, more likely T351821: Edit Recovery interaction with browser data recovery.

I wouldn't characterize it as "forcing" a live diff because the popup is already a JS component and "Show changes" in the edit form would remain unaffected. Rather, it would be more of a surprise if a button on an interactive popup sent you to a different page. A one-time live diff is the less astonishing approach.

By using mediawiki.page.preview but NOT mediawiki.action.edit.preview you can do a live diff just for once. That's what I was suggesting, and it's different from the patch you abandoned.

This is certainly not "when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested" or "when there's a consensus that implementing a particular task would be a bad idea".

It's not just encapsulateSelection(), it's all methods under fn (getContents, setContents, getSelection...).

In T130888#9571178, @thiemowmde wrote:

I think this effectively qualifies as a new feature. very similar if not the same as T130134: Watching (only) categorization (additions and removals) of an arbitrary category.

Can you re-surface mw.loader.addStyleTag()? It's been quite handy, it's used a lot, and the doc for mw.util.addCSS() even mentions it as an alternative.

Indeed, if it's present in mobile diff then we might as well show it always.

Are you sure you're missing the URL only when hovering over a missing file link and not when hovering over any link? Safari apparently does not show the URL by default and you have to enable "Show status bar" to see it. Have you done that?

a sort-of unnecessary page load in the case of live preview

I would find that disorienting. Now that live preview has an API (require( 'mediawiki.page.preview' )), why not let "Show changes" in the notification do an ad hoc live diff, without touching "Show changes" in the edit form?

The textSelection methods are marked as private and thus not showing up in the documentation. They should be surfaced one way or another as they are APIs meant to be used by consumers.

<button> comes with its own quirks so I used <a>, but I wouldn't stop anyone from trying. In the meantime I suggest Cat-a-lot be patched anyway, as even if they did it wouldn't be deployed immediately.

My bad, my prototype for T136907 was loading the module. Not reproducible with safemode=1. Apologies for taking your time 😳

Is there a CSS snippet intadmins can instate temporarily so the issue is fixed, at least locally, until a fix is created and propagated, like T356928 last week?

It appears the template insertion button doesn't get added for those who can't edit the page.

@jpxg said on Discord:

it's the same as before -- it loads something, it's just that this thing is not the code editor and ctrl+, does nothing and there's no line numbers and no highlighting
{F41847334}

That is, the gutter made them think Ace was loading, just not fully. Because that's exactly what it looks like. It looks like the loading of Ace failed halfway through.

In T308423#9500945, @gerritbot wrote:

Change 994391 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Use flexbox for toolbar group items

https://gerrit.wikimedia.org/r/994391

The status quo is the desired behavior. You shouldn't be marking pages you haven't seen in parsed whole as patrolled.

It seems on Chromium the request does go through, so the toggling does occur. On Firefox it doesn't.

In T357202#9531155, @Titore wrote:

Other buttons are not showing up either, i.e. "Mark as patrolled" (for users with the "patrol" user right in wikis with $wgUseRCPatrol set to true).

If I click use desktop site in browser it shows.

It gets hidden when the viewport is <720px wide. The z-index here is too low.

Seems to have caused T357202: Thanks button missing from mobile diff

What would also be nice that was present in JSDuck is the ability to toggle private/protected items.

I didn't have the Navigation Popups gadget enabled and I still got the error.

Does it happen with safemode on for you (i.e. on https://en.wikipedia.org/wiki/Main_Page?safemode=1)?