Today I encountered this issue for the first time. I had taken the time to write a rather extensive message to my opponent. In the past the message has been cut up into many smaller messages for me. But today, I received this error and there was no way to get my message back.
Suggestions
If this outcome is programmed on purpose, I would like to suggest that the Chat box not be cleared. That the user be informed the message will be too long to submit, so they can edit it accordingly.
It would also be helpful to note how many characters the message attempting to be submitted is and what the maximum character limit is.
Haven’t seen this before… @anoek any ideas what happened here?
Gonna also pink @flovo , @RubyMineshaft , and @GreenAsJade as I think they’ve poked around in the chat code before? Might have stumbled upon this?
function chat_markup(...)
if (!lengthLimit) {
lengthLimit = 1024;
}
if (body.length > lengthLimit) {
return [<span key="message-too-long"><{_("Message too long")}></span>];
}
… yes, it is limiting you to 1024 chars.
I agree that dumping them isn’t great. I think it’s worth raising a bug on that: you should be blocked from typing more than the max.
Note to devvers: it’s not clear to me why a routine responsible for chat markup is imposing a character limit.
This should really be done in the input control, eh?
The good news is the message isn’t lost, it’s just not showing since some super long messages were crashing browsers. The limit could probably be increased a bit or we should at least add some sort of input validation.
Yeah - input validation seems to be in order, although interstingly we can’t always control that: phone apps for example can presumably submit non-compliant chat, unless the API also blocks it?
I suppose we’d just have the validation match whatever display limit we have set. It would stop messages that are too long from being submitted on the webapp (or split them up before sending), but third party apps would need to set up their own checks or we’d still show the <Message too long>.
A combination of increasing the limit and implementing a validation would probably take care of the issue for the vast majority of messages though, I’d imagine.
Yeah, I had this before too in a teaching game. It was pretty annoying. Maybe there could be a little indication of characters remaining, like 12 / 1024 to indicate you have 12 characters left till you hit the limit?
I wonder if the markup has always been there, or whether it’s the addition of this that brings the difficulty of splitting?
I certainly find it hard to picture just how you would readily split markup… but maybe that’s me being dense (happens all the time, no surprise there).
The reason that exists is because we had several instances where folks would copy/paste huge blocks of text in an attempt to lag out their opponent, which sometimes worked. We don’t split anymore because it doesn’t fix that. I’m OK with raising the limit from 1024 though, I’m not sure what would be a good value though, nothing too high.
How about posting the first 1024 characters, followed by " (…)" and a message below stating that the previous message was cut short for being too long?
I mean it makes sense except you do have to remember what the rest of your message said since it’s now gone into the void.
I think visually showing people they’re about to run out of characters is necessary with these restrictions. It might not avoid frustration, but at least it explains itself.
I think it’s fine to have a 1024 limit. I think (as we’ve all been observing) the right thing is validation as you type. People are accustomed to this mechanism.
… it avoids this, because it you are typing manually, you get stoped immediately, and if you are pasting you still have your clipboard.
