@Jdlrobson How can I reliably do that? The radio buttons are created client-side. It also feels ridiculous to have to essentially reverse what a script has done instead of preventing it from running in the first place.

@Jdrewniak That defeats the primary benefit of a dark mode gadget, which is that you don't get FOUCs.

Sounds good.

In T369072#9963469, @SToyofuku-WMF wrote:

Hi there! Apologies for blocking your patch, but I did a great deal of research into the existing gadget when writing the code that is currently present and there are a few considerations here that are not immediately obvious:

1. because of the way that the gadget uses both user options and local storage, if the gadget is disabled without disabling the toggle it results in the two falling out of sync
2. I tested the proposed patch locally, and it did not correctly disable the gadget, resulting in an immediate double invert

In general, I'm in agreement with Jon that our implementation was not written to be coexistent with the gadget, and I'm struggling to see a way for us to support both without a considerable amount of effort. If there's a particular reason you're trying to accomplish this we could see what can be done to help, but I don't think the proposed patch is the way to go

In T239796#5713831, @matmarex wrote:

We should probably make option 4 work (action=edit&veaction=editsource). Task T190765 is a similar problem.

That said, I don't understand why you need this. Could you just link to action=edit and let the user's default editor be used? If the page is unsuitable to be edited using VE, then it should be disabled there in some other way (e.g. using a custom content model, or disabling VE in that namespace, etc.).

Now the CSS has a rule for .damaging.damaging.mw-changeslist-damaging-verylikelybad, with two .damaging, which thus overrode my custom CSS.

No, just give me an option that's basically "I don't care if they interfere, just enable these radio buttons" because (1) the toggle gadget alone doesn't interfere in any way whatsoever and (2) the dark mode gadget can be disabled without reloading.

The gadget is not compatible with dark mode, so I'm not exactly sure what you expect to happen here. We can't enable dark mode while the gadget is present in the page.

This has made fixing things for the native dark mode really difficult. I want to continue using the gadget, but I can't test the native dark mode with just useskin=vector-2022. I want to help you, so please don't make doing so difficult.

Also happens on links:

I don't understand why "background-color-content-added" and "background-color-content-removed" can't use different shades of the same colors as "color-content-added" and "color-content-removed" (i.e. green and red), just as "background-color-success-subtle" and "background-color-error-subtle" use lighter shades of the same colors as "color-success" and "color-error".

Possible duplicate of T207383: Inherited methods and members of mixins are missing

How is this different from T363630: Score audio cannot be played if the page has other embedded media?

Why are we defining SpinnerOpts and TableSorterOptions as separate types? confirmable(), highlightText(), makeCollapsible(), suggestions(), etc. also accept options through an object, but they're not defined as types. As a reader I prefer the available options to be documented inside the same section as the method that accepts them rather than having to scroll back and forth.

Why not fire the wikipage.content hook for the ref content?

If ReferenceTooltips copies elements preserving handlers using jQuery, the problem is simply that Phonos uses not $.fn.on() but addEventListener(). If Reference Previews does not preserve handlers, switching to $.fn.on() will not be enough to solve the issue. They seem to require different solutions.

That task is about Reference tooltips, not Refernece Previews.

As evident in hastemplate, "links" in linksto is the third-person singular verb, not the plural noun. linksfrom wouldn't make much sense.

rewrite the documentation using typedefs describing the options for each of the commands.

That would not be sufficient because any callback added via register() should behave the same way as its default counterpart, i.e. accept the same options and return the same expected value. Not just the options but the methods overall need to be documented.

No adequate explanation given why this can't be addressed in MFE.

Would we enable notifying others in production?

Something along the lines of "If you have 'Show preview without reloading the page' on in your preferences, now 'Preview page with this template' also works without reloading the page."

@MusikAnimal Thank you so much for the review!

@Jdlrobson If MobileFrontend meddles with "which skin to display" then it absolutely has to do with this. If it gives you Minerva regardless of the skin preference, then why can't it also override the responsive preference? What's the point of a for-mobile site that doesn't have width=device-width anyway?

I thought the fix for this task might fix T363630: Score audio cannot be played if the page has other embedded media too, but that one is still happening so apparently not.

Not reproducible anymore.

No, it does not behave as expected because Minerva is the skin you're going to get no matter the preference. The responsive mode toggle should be accessible so long as MFE is installed.

This is annoying because now you can't toggle responsive mode for mobile unless you change the desktop skin. Filed T363674.

For one, it has to be styled basically from scratch to blend with text and not look like a button. And it would have to be inserted (or enabled) client-side.

Now called Asahi Shimbun Cross-Search.
https://xsearch.asahi.com/

Seconded. Having Scribd in the collection will likely make it more difficult to court more reputable publishers.

I was just explaining why it works in your first example and it doesn't in the latter. The presence of other embedded media on the same page triggers the use of the VideoJS player for Score-generated audio.

Somehow, the same code works here but here doesn't

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 AFAIU 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.