Fixed.

We attempted to reproduce this in bare VE using a comment node, but the behaviour did not recur.

We were able to reproduce this bug in raw VE using a comment node.

It's doing a little jump before the animation starts, I'll investigate.

I just realised the keyboard is another angle. I installed GBoard.

I've attempted to reproduce with no luck. @Esanders could you confirm I'm taking the right steps here?

Could you provide a minimal example of a page that breaks? I've been having trouble reproducing this.

Good point!

Signing off for the day, here's where I got:

i fixed up my caches so that partial caches from failed runs don't mess up the subsequent run. I tried lxml, which allegedly is better for avoiding OOMs while parsing XML, but it's still OOMing so possibly it wasn't there.

Logging some useful commands. On toolforge having done become zoe-oneoff-scripts:

I've modified my script which downloads thread info to accept an endpoint and an output file, and summarised the sizes of these wikis in terms of LQT threads:

I've tried using focusin and focusout events, but this doesn't seem to fix the issue. I think there's something funky going on with focus as clicking around inside of a RadioSelect causes the events to fire where I wouldn't expect them to (both for the focus/blur family and focusin/focusout).

Ah, good catch. Well, I'll be treading delicately...

Quick survey of what's got Flow and what has LQT:

I'll probably have to work my way through this sporadically, so I apologise in advance for things coming in comment by comment.

@Pppery I've written a community notice, we're reviewing it internally and are hoping to have it translated and up on ptwikibooks next week. I'm currently proposing that we give a weeks' notice and then execute everything in one go, unless the community wants us to make changes to that schedule.

Good news: looks like DiscussionTools exists by default and I don't need to enable it manually

There's complexity because this involves an interaction between two specific checks and we may have to discuss further how to approach this

Phew! I think I may have broken this down into too many tickets.

Technically a duplicate but that task is doing double-duty further up the tree. I've suggested reparenting that task at which point this one would be a duplicate. For now, reopened so I have its checklist somewhere.

This task has become a parent task of much of the LQT undeployment work. I propose we rename it to Undeploying LiquidThreads

This set of tasks is quite confusing. In particular, this task pertains to freezing LQT on ptwikibooks, but then has subtasks about undeploying LQT in general.

Closed as a duplicate of T114278: Freeze LQT on pt.wikibooks (pending since 2015)

I've come in a bit heavy-handed: of course this is the ticket for _all_ LQT wikis, not just ptwikibooks. I've taken out the ptwikibooks-specific things from the description again – sorry about that, and the spam.

This ticket has become somewhat detached from its child ticket, T388099: Inform ptwikibooks of LQT and Flow removal plan and timing, where most of the discussion has been happening, as well as quite a bit of work on T397426: Implement bulk fixes on ptwikibooks before that was broken into another ticket.

Minor error, I'd made a field expect_revision instead of expected_revision. Fixed file:

Just in case it's needed, here's a copy (from today) of all the LQT threads that the API returns: