Are you doing the same thing TBest is doing? His comment did help me reproduce the "commenting position after" situation.
If this is happening after scrolling through moves, I'm split on whether this is intentional or an oversight. It hinges on the difference between clicking and scrolling; I could poke around Discord to see if anyone knows more.
If it's happening through some other means, such as clicking on moves rather than scrolling, that's a different situation and more likely a bug.
If this is happening after scrolling through moves, I'm split on whether this is intentional or an oversight. It hinges on the difference between clicking and scrolling; I could poke around Discord to see if anyone knows more.
If it's happening through some other means, such as clicking on moves rather than scrolling, that's a different situation and more likely a bug.
I think so. I guess I have a habit of clicking on the text box and when I'm finished with , just finding the next move to comment on via the top right move pane. It's really annoying to even have this "commending position after" functionality in the first place though. Just let me write without this message please.
The "commenting position after" text disappears immediately after I try to reproduce what Tbest says. Was the source code updated?
I can still reproduce TBest's steps. The source hasn't been upated in this area of the codebase.
The more I investigate, the more I think the behavior that I observe is intentional. Here's what I observe:
As long as you remain focused on the comment box, the text in the comment box will not change.
If you are not focused on the comment box, navigating to a different move will update the comment box to comment on that move (after a 100ms delay, which is why you sometimes see a flash of "commenting position after").
Clicking on moves always takes focus away from the comment box, so clicking should never result in "commenting position after."
Navigating to another move using the scrollwheel does not take focus away from the comment box, so it results in "commenting position after."
I'd argue this behavior is intentional because it aligns nicely with the focus behaviors that users have already learned from using browsers. Now, if you observe something else, that's probably a bug.
The more I investigate, the more I think the behavior that I observe is intentional. Here's what I observe:
As long as you remain focused on the comment box, the text in the comment box will not change.
If you are not focused on the comment box, navigating to a different move will update the comment box to comment on that move (after a 100ms delay, which is why you sometimes see a flash of "commenting position after").
Clicking on moves always takes focus away from the comment box, so clicking should never result in "commenting position after."
Navigating to another move using the scrollwheel does not take focus away from the comment box, so it results in "commenting position after."
I'd argue this behavior is intentional because it aligns nicely with the focus behaviors that users have already learned from using browsers. Now, if you observe something else, that's probably a bug.
Even if this behavior is intentional, may you please consider adding an option for users to turn it off in their settings somehow? I feel like this is one of those "smart settings" sites have to make the site supposedly easier to work with.
I understand if you won't. Just feels like bloat to me, but for others, maybe not so much. It'd be nice if lichess had an "Advanced Settings" panel for users to access beyond the basic stuff in the backend.
I understand if you won't. Just feels like bloat to me, but for others, maybe not so much. It'd be nice if lichess had an "Advanced Settings" panel for users to access beyond the basic stuff in the backend.
I should clarify: the reason for this behavior probably has nothing to do with scrolling. This feature exists because multiple people can edit a study concurrently, and if person A switches to a different move while person B is editing a comment, Lichess tries to avoid interrupting person B's editing.
So I take back some of what I said. The feature is intentional, but I don't think it was designed with scrolling in mind. I made an issue on Github to see if there's anything else I'm missing, but if not, I should be able to land a fix.
github.com/ornicar/lila/issues/9599
And just to confirm, this only happens when you scroll with the mouse, right? Otherwise the fix I have in mind won't help you.
So I take back some of what I said. The feature is intentional, but I don't think it was designed with scrolling in mind. I made an issue on Github to see if there's anything else I'm missing, but if not, I should be able to land a fix.
github.com/ornicar/lila/issues/9599
And just to confirm, this only happens when you scroll with the mouse, right? Otherwise the fix I have in mind won't help you.
Yeah, I think its kind of related to the scrolling. Can't remember a time where scrolling wasn't involved. I have a hard time replicating this like you did.
I'll let you know if it keeps happening, but at that point, it'd be me just nagging you (and the devs) and I don't want that.
I'll let you know if it keeps happening, but at that point, it'd be me just nagging you (and the devs) and I don't want that.
This is just correct behavior IMO. "Fixing" it would cause way more unpredictable behavior instead.
Pro tip: with your focus on the board/move list, click g then d to close and re-open the comments at the bottom. Now you'll be commenting on the current move. That should be a reasonable enough workaround to deal with your specific problem.
I can still see why the current behavior should still be the expected behavior.
I can still see why the current behavior should still be the expected behavior.
This topic has been archived and can no longer be replied to.