Chess960 castling issue in study (with REC)

[tors42]

Exact URL of where the bug happened

https://lichess.org/study/71wF4VyX/o5xpWV4i

Steps to reproduce the bug

1. Create a Study
2. Create a Chapter, use PGN tab:

[Variant "Chess960"]
[FEN "rnbbknqr/pppppppp/8/8/8/8/PPPPPPPP/RNBBKNQR w KQkq - 0 1"]

1. f4 d5 2. d3 f6 3. e4 e5 4. exd5 exf4 5. Bxf4 Qxd5 6. Nc3 Qf7 7. Bf3 Ne6 8. Be3 c6 9. g4

3. Navigate to last move
4. Make sure REC is on
5. Try to castle (Drag king from e8 to g8)

What did you expect to happen?

Move should register as castled ok

What happened instead?

Move registered shortly but instantly reverted.

Operating system

Mac

Browser and version (or alternate access method)

Firefox 149.0.2

Additional information

• Originally reported in Discord - https://discord.com/channels/280713822073913354/1491155803447628029
• When REC is on, web socket traffic happens (one can see "e8", "g8"), when REC is off, no web socket traffic happen and the move registers succesfully...

[ddugovic]

Interesting. I assume this 960 PGN with KQkq castling rights came from Chess.com.

[tors42]

Interesting. I assume this 960 PGN with KQkq castling rights came from Chess.com.

I have no clue about their origin, but I did today notice KQkq notation and tried to replace with HAha and the problem still happens.

I think I recall there's been some changes in Lichess how castling is uci-represented in different interfaces (i.e when streaming and playing games) - something about the target square being the square the king wants to move to vs the target square being the rook the king wants to "castle with".

[ddugovic]

Yeah... even more interestingly, I retested first on https://lichess.org/paste which works then study which errs (Chrome on Chrome OS).