mojira.dev
MC-7181

UTF-8 char locks Textbox

Pasting the char ( in any Textbox will make Text after it invisible. If you set it as World Name you still can use the world, but the Text in the Box is missing. This makes Worlds without Names possible.
Please note, that the char is not an open parenthese and you need to copy-paste it. The Directory created for the world contains this char and looks regular.

Linked issues

Attachments

Comments

Kevin Gut

Example of an empty name due to UTF-8 Bug

Kevin Gut

Textboxexes seem to accept most UTF-8 chars.

Kevin Gut

Version 1.5 is still affected

bugi74

Fix

FontRenderer.renderUnicodeChar(char c, boolean italic)

...
        //int startColumn = this.glyphWidth[c] >>> 4;
        int startColumn = (this.glyphWidth[c] >>> 4) & 15; // FIX
        ...

Tested on 1.4.7, works wonders.

Reason was that the byte for 'glyph width' is handled as unsigned value, whereas Java only does stuff as signed values (except 'char' of course) and bit-operations in 32-bit things. Before doing the bitshift (which does have the nice >>> op), it will sign-extend the byte. If the high nibble has large enough value (8..15), it basically means the byte has negative value, and thus the 32-bit integer being shifted is also negative and has 24 extra 1-bits on left. After the shift, such integer value converts into a very large positive value. The start column was thus calculated to be a very, very, very large thing, causing multiple problems, like rendered width to be millions of pixels. (The rest of text was thus way past the visible area.)

For that particular character used in the description: its codepoint is 65288, glyph width value -100 (or nibbles 9 and 12), and the shifted result for start column 268435449!

Kevin Gut

instead of int it would be better to use an unsigned int. wouldn't this solve the problem?

bugi74

Kevin, I recommend reading my analysis more carefully, or alternately, reading Java language specification. Basically, Java does not have unsigned integer values. The only exception is 'char', which is basically unsigned 16-bit integer with a little bit of unicode related sugar. Unfortunately, as soon as any kind of math/bit-operation is done with such value, it is implicitly converted into 32-bit signed ints, and all kinds of headaches and keyboard throwing contests ensue.

But yes, using such unsigned integer value would have done the trick.

Kevin Gut

Updated the issue, still present in 1.6.1

Ezekiel

Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

bugi74

Still in 1.6.2

galaxy_2alex

Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Itouch2

Still affects 1.7.4/5 and 1.8

Itouch2

Confirmed for 14w18b.

Kevin Gut

Yes it is still a concern with the newest version

galaxy_2alex

Reopened, thanks

marcono1234

Duplicates MC-13046

bugi74

Original descriptions are somewhat different, but indeed, the same cause (incorrectly calculated widths) is behind these issues. So yes, a duplicate. (Marcono and I even found the same fix independently.)

Kevin Gut

(Unassigned)

Community Consensus

Minecraft 1.4.7, Minecraft 1.5, Minecraft 1.5.1, Minecraft 1.6.1, Minecraft 1.6.2, ..., Minecraft 14w07a, Minecraft 14w08a, Minecraft 1.7.5, Minecraft 14w18b, Minecraft 1.8.1-pre3

Retrieved