In T381537#10411269, @MusikAnimal wrote:

Related, I wonder why we don't take more advantage of polyfills. Array.prototype.includes() for example is a tiny implementation, and would make JS developer life so much easier.

One way to mitigate the problem is to make EditRecovery compare the current form values against the defaultValues instead of keeping an originalData object. That way a script would be able to modify the defaultValues to "reset" EditRecovery.

Hmm, I can't reproduce it without turning it off either anymore.

No, but either way I get the same error.

per-wiki, using $wgPhonosButtonClasses, which can be set to eg. [ 'noexcerpt' ] to preserve the current behavior;

Couldn't this be an abuse filter?

That ticket makes clear the feature tests were carefully discussed and designed. It's the linter that's out of sync, not the other way around.

It's in T178356.

Searching for "Chini.png" and "Queer Man Peering Into A Rock Pool.jpg" does accurately bring up https://en.wikipedia.org/wiki/Chini.png and https://en.wikipedia.org/wiki/Queer_Man_Peering_Into_A_Rock_Pool.jpg, so they're clearly capable of indexing wikipages ending in an apparent extension (NB Bing fails to show the latter in the main results). One wonders why that doesn't apply to the File namespace.

The only downside I see is that it might be confusing to select these options, and then for nothing to happen - clicking away from the dialog is an opaque requirement. As such, maybe a 'confirm' or 'update' button inside the dropdown would be helpful, to make this explicit?

Updates don't take place as options are selected until the user clicks away from the dropdown.

This is the most straightforward (and least workflow-breaking) of the three. Updates happening in the background would likely result in rapid flashes of the list, which would be disruptive to the eye (and I imagine to the screen reader), and waste of traffic.

It is affecting end users, unless this is unrelated:

In T379983#10324771, @TheresNoTime wrote:

searching (Vector 2010) and using arrow keys to navigate the search results is not working as expected (gif below, I am just pressing the down arrow):

I haven't been a fan of "review" though. One doesn't expect it to lead to a diff (note you can't really do anything unless you have the right). "Review changes" would be at least more understandable.

someone else suggested making the header say "Action"

That would make a column headed by "Review" full of cells with just "Review". That's hardly descriptive. I'd make the cells say "Diff" (someone else suggested making the header say "Action", which would also be at least better than "Review" all the way down).

Haven't tested it, but this suggests the same goes for adding a short description. (It also shouldn't suggest adding one when it's deliberately unset...: T326898)

#1080108 appears to be the culprit.

In T356292#10260104, @Nardog wrote:

<li> elements with "(current)" on Special:Contributions no longer have the mw-contributions-current class. The class is still in the code, so I assume this is by mistake and #1080108 had something to do with it.

<li> elements with "(current)" on Special:Contributions no longer have the mw-contributions-current class. The class is still in the code, so I assume this is by mistake and #1080108 had something to do with it.

Well, I know how to turn it on yet I haven't because I find it distracting. I just use Ctrl+Space if I want it.

@SD0001 Feel free to submit a patch of your own.

How about a toggle button too? Not all users would like it. (T61924)

the category existence check has already happened on the first server loading of the edit page which is the only load for live preview

This is somewhat old news but it saves so much of developers' time I think it still deserves publicity. Something like:

⚒️ You may now temporarily use the 2017 wikitext editor, even if it's not enabled in your preferences, by adding veaction=editsource to the URL.

Then the problem is with Phonos, added for T345414.

We don't tell CodeEditor or Ace what environment the code is supposed to run. Nor should we. There is no way to tell whether a .js page is supposed to run in "the MediaWiki Javascript environment" (where globals vary by what modules are loaded btw) or it's just put on a wiki for reference or as a snippet. The strict mode prohibits undeclared variables, so the warning is correct, and explicitly declaring the globals in a comment already exists as the solution.

Not a bug. 'use strict' prohibits undeclared variables, so the linter is right to warn you about them. Just put /* globals mw,$ */ or ignore the warnings.

Oh, you're right. I was looking at "diff"/"hist" instead of the timestamps.

Through T336763.

I'm talking about Special:PendingChanges.

If PendingChanges should be a table, surely so should this...

Do not rely on iconography alone to represent categorical information in headings

Not reproducible anymore – "diff" doesn't have a tooltip, and the tooltip for "hist" is correct. So is title= in the URL (I'm not sure if this was ever wrong).

I guess addButton() in ipReveal.js is supposed to be for this purpose? But it's not exposed outside the module. Not only that, the automatic showing of recently queried IPs does not happen with just addButton() (it's duplicated in initOnHook.js and initOnLoad.js, why not bundle that into ipReveal.js also?).

Fixed on my end too, must have been a temporary issue.

In T370803#10022554, @Tchanders wrote:

Thanks for looking into the APIs @Nardog.

In T370803#10012663, @Nardog wrote:

ApiFeedWatchlist seems to be working, but ApiFeedRecentChanges does not:

• https://test.wikipedia.org/w/api.php?action=feedrecentchanges&hideanons=1

This seems to contain no temp accounts...

• https://test.wikipedia.org/w/api.php?action=feedrecentchanges&hideliu=1

...whereas this contains temp accounts. I believe that's correct, or am I missing something?

In T370803#10008214, @Tchanders wrote:

Thanks @Nardog.

Looks like ApiQueryWatchlist and ApiFeedRecentChanges should have been fixed in T341228: Update action API to handle temporary users.

We should look into ApiFeedWatchlist - seems to have also been missed.

Turns out anon/!anon already work in watchlist and feedwatchlist.

Does this task also cover ApiFeedWatchlist? anon/!anon seem to be already working correctly.

ApiQueryWatchlist, ApiFeedRecentChanges, and ApiFeedWatchlist also have anon/!anon or hideanons options.

Fixed, the double negative failed me.

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