please add to the reproduction steps the following:

• add some active hidden categories to your watchlist

with all due respect, deliberate product decision does not automatically imply it's not a bug.
there are "bugs by implementation" (the more common case) and "bugs by design" (for which this is an example).

T127944 says "Categories with HIDDENCAT should not be displayed on wiki change lists unless user has the "display hidden categories" preference turned on"

two issues here.

1. the task itself is a mistake (i.e, "design bug):, IMO. when someone adds a hidden category to their watchlist, they expect to see changes (addition and removal of pages from the cat) regardless of the "show hidden cat" preference: the preference should control whether or not the hidden categories appear in the "categories" box at the bottom of the page, but not block watch items. if dev insists on the current (wrong) behavior, at the very least, these should happen:
   1. i when a user adds a hidden category to their watchlist, they should be notified that they will not see changes in the category without turning on the non-default "see hidden cat" preferences.
   2. similarly, when a user turns on the "show changes in cat" filter, they should be notified that they should be warned that they will no see changes to hidden cat.
   3. when a category is made "hidden", users who are watching it unexpectedly stop getting notified when pages are added and removed
2. the implementation itself is buggy: the bug here is that changes to hidden cats are not shown but they are counted. in the "error sate" watching a hidden cat while the preference to see hidden cats is off), if my watchlist is configured to show 100 changes, and someone does something radical which fills or empties such a category with more than 100 pages), the watchlist will show empty, i.e., the hidden cat changes push other changes out of the watchlist (i.e., they are counted), but are not shown. this behavior contradicts the normal/expected filter behavior: changes filtered out of the watchlist are not counted, and the list shows the maximum number of changes which do pass the filter.

second real-world use-case:

In T107119#8629980, @Krinkle wrote:

@jeblad @Kipod

I notice the task description is currently prescribing a very specific solution, but lacks any description of a currently experienced problem ("bug") and also lacks any high-level outcome that it would enable ("feature"). It is not uncommon than once the reason for something is understood, the maintainers and other developers like yourself, might iterate on the idea and come up with a perhaps even better solution. This is currently not possible though, and is likely why it has little engagement and low priority. It's currently Yes/No situation without any apparent downside or invitation to help.

TLDR: Why do we want to load TemplatatData into Lua? What are some use cases for that? I can imagine some of course, but I'd like to hear yours.

In T363053#9732636, @thiemowmde wrote:

Unfortunately not, sorry. At the moment the ticket explains neither a solution nor a problem. What is the user story? How should the new syntax look like? How should it be presented and explained in the interactive TemplateData editor? How should it be documented? How should consumers like VisualEditor, the MediaWiki-extensions-TemplateWizard, Citoid, or the ContentTranslation workflow behave? Should this really block the user's edit from being saved? How would this look like in the UI? What does the error message say? What if the template already contains an unknown value that wasn't entered by the current user? Should we still block the user from continuing what they wanted to do? Why? How do we explain it to the user? How do we help the user to get unstuck? How do we measure the success rate to make sure the change was worth it and we don't loose meaningful edits due to users getting frustrated and giving up?

This is very similar to what I said in T197634#9712254 just a few days ago: I think what we are discussing here is called "programming" and requires an actual programming language. Which we have: Lua. It's the job of the template to decide if it wants to accept unlisted values, ignore them, or trigger an error. Why would we need to duplicate this logic in a different place an entirely different format?

i am asking for minimal change, in TD validation only.
the other stories may be viewed as asking for some behavior change (mainly VE support), all i'm asking here is to allow two specific "parameter" attributes in TD validation.
code (and doc) changes should be minimal.
unfortunately i am not able to submit pull request myself, but i imagine such change should not be more than a dozen or so lines of code (most of which as comments)

T54582 asks a bit more,=, it asks for VE to behave in a certain way. this request is more modest: all i ask is to allow 2 more attributes.
there's strict validation code that doesn't let you save a page which contains invalid TD, and this request is to allow two more attributes, with suggested names.
it should be straightforward and short to implement, maybe even simpler than documenting it.

In T354383#9437737, @Esanders wrote:

I get a warning in both Firefox and Chrome when I press back. The only way I can get no warning is if I press back very quickly after the preview loads.

In T354383#9436556, @Aklapper wrote:

Which source editor? See https://www.mediawiki.org/wiki/Editor

this is not wikidata specific, and already hit the "early upgrade" wikipedias such as cawiki and hewiki. for details and links, see T338405

this is an old, practically abandoned story.

In T315639#8204471, @Jdlrobson wrote:

We simply wouldn't be able to change anything if we had to retain all existing CSS selectors and IDs. I don't know if you do development yourself, but if you do I'd urge you to take a moment to think
about how a constraint of not being able to change any ID would impede you with developing a MediaWiki interface.

In T315639#8175177, @Jdlrobson wrote:

....
Impact doesn't seem quite so bad. I'm only seeing 1408 cases across all wikis for JS files (I don't think it's worth focusing on CSS here).

In T315539#8166643, @MusikAnimal wrote:

They should instead file a Wikimedia-Site-requests to change the thresholds for semi-protection.

IMO, the exploit should not be exposed, to avoid causing more pain to sites running vulnerable versions.

just to clarify: the issue is that this was allowed until last version, which means there are already "live" templates which violate the assertion.
this caused significant disruption: specifically, one of these templates was the hewiki equivalent of "Cite journal" - as a result, editors could not create automatic citations of articles using DOI, and could not even create manual such citations using VE (and thanks to mediawiki devs, many editors don't even know how to use source editor - kudos!).
we went and amended those templates on hewiki (can't be sure we found them all - see below :) ), but it's more than likely similar issue still exists on other projects.

we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

just realized that this error does not add the template to any tracking category. make it 2 demerits.

beg to differ.
when ply is not defined, the final state of the game may or may not be useful to readers not using the interactivity, but the opening board is guaranteed to have zero value.
if you are 100% against showing the last ply, it would be better to declare ply= "mandatory" parameter, and show error when not defined, rather than defaulting to absolutely useless real estate on the page.

no need, thanks.
your explanation clarified it, and the comment is junk.

@4nn1l2 - please see update to story and consensus, and my comment on gerrit.

speaking of the algebraic notation, i would like to suggest some css tweaks to make it clearer that the plys are clickable.
cursor:pointer comes to mind.
another css change i request: please replace the bike and ped icons for fast/slow with dear/snail, as in the prototype. turtle would be even better.

description should be expanded to cover ply and swap.

i think you should obtain a simpler PGN with NAGs and test it with it.
the game on my user page was copied from one of the test cases in the extension's repo, but i do not know that it's valid.

@Wugapodes : can you see why 3rd game in https://en.wikipedia.beta.wmflabs.org/wiki/User:%D7%A7%D7%99%D7%A4%D7%95%D7%93%D7%A0%D7%97%D7%A91/ChessBrowser_test_cases still fails to parse?
i copied it from one of the test cases in the repo.

(critique based on the screenshot only)

@Wugapodes
now it seems that it does not like the question mark in the doc, and complains about

@param array? $fenParts The ....

on lines 149 and 214 of includes/ChessParser.php

@Wugapodes :
it says

looked at the beta.
saw for the first time how "flip" also rotates the board itself, not just the button. super cute.

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

interestingly, the first implementation of the standalone introducing speed control used slider.
never got it to be satisfactory.
if i may, i think it will be better and more useful to have a single "speed control" button, which will allow the reader to enter the delay numerically.

lichess is not the model.
look for any site which holds large library of games in PGN format, and look at the interactive game interface. first i stumbled on (from enwiki article) https://www.chessgames.com/perl/chessgame?gid=1129672
autoplay is useful feature. talk with chess aficionados. at the very least we should consult the authors. i asked on their talk page. (see enwiki:Wikipedia talk:WikiProject Chess ).

several comments:

@sbassett : currently, the beta deployment task, T244075 depends on this task.
iiuc, there is kind of agreement that the extension can be deployed to test wiki, maybe under some conditions.
can you please update the beta task, and clarify if it can progress despite declining this task, and if so, what needs to be done?
maybe it's clear to everyone but me...
peace.

(not very useful comment):

In T269222#6716104, @Aklapper wrote:

Please contact the Chrome/Chromium developers (or use another browser).
In my understanding, there is nothing we can do/fix on our side hence closing this ticket.
See also T269222#6681319.

I added a wishlist item to add this extension to wmf wikis.

fwiw, i added to mediawiki:minerva.js on hewiki the following line, and the pencils are visible again.

first of all, this is different than the error i see in the console when adding debug=1, which is

can someone please explain

on further examination, it's a bit more complicated than than.

i would add specific chess cases, to verify correct pgn parsing:

1. en passant
2. castling
3. promotion

currently, on wikimedia sites, the parsing _is_ lax, despite what the documentation says.

In T167423#3990447, @brion wrote:

3D has been deployed to Commons, but not yet to the other wikis, so files can be uploaded but not yet used in articles. It'd be real nice to have mobile support working when that further deployment goes out so we don't have a bifurcated experience for our users -- is there any current work on this?