[question] Inconsistent client behaviour when receiving long text messages.

[BafDyce]

When sending very long text messages, there is some inconsistent behaviours by the official mumble clients. First some facts:

• The mumble server in questions allows a maximum text message length of 20480 characters (afaik the default value is 5000).
• A user (actually a bot using the pymumble library) is sending two text messages:
  • The first one has a message length of 20463 characters (20469 after serialization and a total packet length of 20475)
  • The second one has a message length of 13246 characters (13251 after serialization and a total packet length of 13257)

The following behaviour is observed:

• The mumble server does NOT reply with TextTooLong messages (as it would be the case if a message was longer than the allowed length)
• Different official mumble clients handle the messages differently:
  • mumble 1.3.0~2729~g2126495~snapshot on Linux (Arch, 64-bit):
    • 1st message: [[ Text object too large to display ]]
    • 2nd message: message is displayed
  • mumble 1.3.0~2729~g2126495~snapshot on Windows (8.1, 64-bit):
    • both messages are displayed
  • mumble 1.2.19 on Windows (10, 64 bit):
    • both messages are [[ Text object too large to display ]]

So, while the server accepts the messages and forwards it to the official clients, all of them handle them differently. We could not find any setting which would control this behavior, so we assumed that it's controlled by some hard-coded value in the source code. However, by reading/searching through the source code I could not find the source code in judge of this.

My primary questions now are:

• Where is this behavior controlled?
• What explains the differences between the different versions/platforms?
• Is there any reliable way to find out what the maximum text message length is which is supported by all connected clients?

[hacst]

That code can be found in Log.cpp (https://github.com/mumble-voip/mumble/blob/master/src/mumble/Log.cpp#L429):

    int messageSize = s.width() * s.height();
    int allowedSize = 2048 * 2048;

    if (messageSize > allowedSize) {
QString errorSizeMessage = tr("[[ Text object too large to display ]]");

It checks the potential rendered screen surface area in pixels of the message. The idea was limit display size as with html formatting even very short text can be made to take up pretty much arbitrary screen space. I'm not sure in what way this interacts with DPI / scaling configurations but I doubt they those were a considerations when this was introduced.

I assume the inconsistencies you are seeing are due to text rendering differences on the different plattforms, versions and/or systems you tested.

This also means you cannot really know how big your message can get before the client decides it is to big for it to render as that depends on client-side (system) configuration. If you want to be reasonably sure it is displayed cap it before it well before it gets to the limit on a normally configured system.