(That this APPLICATION_ROOT is needed at all is a bit odd – after all, Flask seems to know that it’s mounted under /speedpatrolling/ when forming URLs in url_for() – but I couldn’t find a better solution at the time.)

I think at least in my tools, session handling is also generally broken on the new domain. For example, if you go to https://speedpatrolling.toolforge.org/settings/ and try to save settings, you get a CSRF error. (Which is not a nice error page because I was lazy.)

https://tools.wmflabs.org/docker-registry doesn’t redirect to https://tools.wmflabs.org/docker-registry/, causing scripts to be loaded from the wrong location:

Yeah, at least it’s not a regression – this is the earliest WMYHTW email I have:

One big question I have is how this should behave when there are more backlinks than fit on a page? I see two main options:

But anyways, I’ve tried to improve the behavior in case of CSRF error a bit, too.

That’s weird, because the last error in the server logs is from January 12th (and that one was caused by me).

I’ve been getting annoyed for months at users adding descriptions with initial uppercase letters (I’d notice it in SpeedPatrolling, which doesn’t provide an easy way to fix the issue) – but small wonder users kept making this mistake, if the app actually shows them the wrong version of every description! Yes, please fix this :)

@Daniel_Mietchen from the server logs, it looks like the first time you used bulk mode, it worked – maybe you used the browser’s “back” button after that and then tried to submit the form again? In that case, try if reloading the page first helps. (Tech details: each POST invalidates the CSRF token; reloading the form gives you a new token, whereas going back and submitting the form again reuses the same, now invalid token.)

In T242573#5796366, @Bugreporter wrote:

(also @Lucas_Werkmeister_WMDE )

That warning is from my code, but you don’t need to worry about it (happens here as well). It doesn’t mean that the code gives up, it just warns you that it might break something and then goes ahead. (168 is the actual number of elements – the syntax highlighting – not a limit.)

It’s working fine on my end (Chromium 79.0.3945.117, Arch Linux). I think most of the messages in the console output aren’t from my code – jstree has nothing to do with me, and this “message port closed” message also seems to be some extension thing – so I’m not sure how to debug this. Perhaps you could try with extensions disabled? (Firefox has a “restart with extensions disabled” feature to make that easy, I think, not sure about Chrome.)

There's some HTML attribute you can add on the input to prevent this (I don't remember the name right now, but I used it in Wikidata Lexeme Forms); we should use it.

Well, I'm not on my laptop right now, but I did find something via my phone:

Thanks! Do you know when it’ll be updated in MediaWiki? I discovered this while working on a gadget, so I’ll have to keep my workaround until the fixed version is shipped via ResourceLoader.

It's back?!?

Patch-For-Review: wikimedia/jquery.i18n#206

Can't reproduce anymore 🤷‍♂️