Currently, the input box only supports single-line input. When I want to send longer messages, I have to type everything in one line, which makes it difficult to read and edit.
I made a local modification to change the chat input box from single-line to multi-line. The default initial height is 1 line, and it automatically expands based on the content (with a maximum height limit).
Should Shift+Enter be handled for line breaks? Personally, having Enter send the message directly works fine for me. Also, in-game chat typically isn’t very long, so paragraphs don’t seem necessary. But I’m not sure about other people’s habits.
If people think this is valuable, I can further improve it and submit a PR. Any suggestions for improvement are also welcome.
I should be honest – the current state of my modification is not very elegant visually. Any advice on how to improve?
Update:
I’ve added a character counter to the top-right corner of the input box.
When the content you enter approaches or exceeds the allowed length limit, the counter will automatically appear and show a warning. This way, everyone can notice the message is too long before sending it, and trim or split it in advance — effectively avoiding the <Message too long> error.
Great suggestion. Private chats are implemented with a different component, so the same feature won’t apply directly. But it’s definitely worth addressing. I’ll be giving it a try sometime soon.
For third-party app devs: my app has been manually splitting messages over 300 char to match the web app. If I remove that across the board will anything break, or do I need to selectively remove it just for the main chat channel?
The server rejects messages over 1024 characters with <Message too long>, so I’d suggest keeping the splitting logic in place. Just raise the split threshold from 300 to 1024 and compress consecutive whitespace characters (spaces, tabs, newlines, etc.).
Also, be careful with the number of splits — sending too many messages in a short time will trigger the anti-flood system.
This is merely what I have observed — it may not fully align with the actual backend behavior.
I think there is a intermittent but breaking error with the current implementation. When on mobile phone (iOS, iPhone 14), the “send/enter key” sometimes becomes a “new line” button instead of “send message”.
When that happens, there is no way to send the message, because pressing it again only adds more lines.
In order to send it, I had to delete the message, send a single line message (works) and then the function of the “enter/send” button was restored. I can’t reliably reproduce it. I thought perhaps a certain character limit or having a couple of lines already flips the behavior but that isn’t it as far as I could figure out.
The current implementation uses: !e.shiftKey && e.key === “Enter” to determine the send behavior.
I’ve repeatedly tested this on my local environment (iOS 26.4.2 / iPhone 15 Pro), but I have not been able to reproduce the issue. These kinds of probabilistic or intermittent issues are often very difficult to reliably reproduce locally.
I’m not entirely sure, but based on the behavior described, it may be related to a temporary inconsistency in the iOS input method state, which causes the keydown event behavior to differ from that of a hardware keyboard.
I’m unable to reproduce this on my side. If possible, more detailed steps or context before the issue occurs (such as input method state, cursor movement, or typing sequence) would be helpful for further narrowing it down.
