mojira.dev
MC-149792

Client book length mismatch resulting in crash

Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.

Concrete steps to reproduce:

  • start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world

  • start a 1.14.x client, convert/open the world, open the book

Or use the following command in 1.14.x:

/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}

What can be observed:

  • clicking on or marking the last character of the book -> crash

  • going to the last character with the right arrow doesn't go to the very end, but stops at a character before it

  • trying to remove characters where a '§' is results in seemingly the wrong character being removed

  • most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position

This means that on a click in lines containing '§' the position/character length is calculated wrongly

i.e. copy and paste

§nVery cool text
§r §§§§ hi

§5and even more
§etext

The older 1.14.3 crash log had a different stacktrace ❓ , this is the latest

1.15.2: crash-2020-04-28_15.38.46-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 44
	at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
	at java.base/java.lang.String.charAt(String.java:711)
	at dch.a(SourceFile:454)
	at dha.mouseClicked(SourceFile:779)
	at dbo.b(SourceFile:86)
	at dgb.wrapScreenError(SourceFile:447)
	at dbo.a(SourceFile:86)
	at dbo.c(SourceFile:150)
	at ais.execute(SourceFile:94)
	at dbo.b(SourceFile:150)
	at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36)
	at org.lwjgl.system.JNI.invokeV(Native Method)
	at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101)
	at com.mojang.blaze3d.systems.RenderSystem.flipFrame(SourceFile:98)
	at cxx.e(SourceFile:301)
	at dbn.d(SourceFile:1012)
	at dbn.d(SourceFile:619)
	at net.minecraft.client.main.Main.main(SourceFile:204)

Linked issues

Attachments

Comments

violine1101

Can you please attach the full crash report here?

Nassim Jahnke

Yep, attached it (now it's also the correct one 👀)

Nassim Jahnke

Yet to be fixed in 1.14.1-pre1

violine1101

As the reporter of the ticket, you can update the affected versions yourself.

Note that 1.14.1-pre1 is currently mislabeled as just "Minecraft 1.14.1".

Beni Berardi

Same bug still present in 1.15.1

user-8373e

Same bug still present in snapshot 20w17a (for 1.16)

marcono1234

In 20w17a I am only able to reproduce

  • incorrect cursor position when clicking on line with formatting characters in them

  • removing formatting character does not remove the formatting code character and vice versa

But I am not able to reproduce the crash, are you still able to reproduce that?

I have added a command to the description which should allow reproducing this in 1.14.x without the need for upgrading a world, though maybe it behaves differently and therefore not all issues can be reproduced with it?

Nassim Jahnke

Right, I can't reproduce the crash in 20w17a anymore either (tested same behavior and world between 1.15.2 and the snapshot) - so only the misplaced cursor remains

violine1101

It might make sense to resolve this ticket as fixed and create a new one for the cursor mismatch then.

Pelle Reinke

Have just experienced the game crash in 20w17a when I clicked on Done after writing a couple of pages of text in a book.
No special characters or formatting were used in the book.

Have attached a crash report

[media]

Mod note: Attachments have been removed because they would later be irritating. As pointed out by @unknown, these are MC-179868.

Pelle Reinke

And it happened again, this time when clicking on the "Going Back Page" arrow

Have attached crash report

[media]

boq

That's a separate issue (MC-179868) that will be fixed in next snapshot.

Nassim Jahnke

So I suppose a mod could close this issue and I will create a new one for the mismatched cursor specifically? (since the original crash issue seems to be resolved with one of the latest snapshots, at least since 17a)

marcono1234

Yes, that would be good. Do you want to create a separate report for removing the formatting symbol (§) or the formatting code behind it not removing the respective other (since that is mentioned in this report here)?

Nassim Jahnke

Created a new issue for that now MC-181539
... or should misplaced clicking and the character removal be split into 2?

pokechu22

Can confirm, fixed in 20w17a (and present in 18w43a, 20w16a and 1.15.2).

In those past versions, I was not able to reproduce a crash by simply clicking on the last character (or anywhere in the last line). I had to make a selection (either by clicking and dragging, or by double-clicking, or by clicking somewhere near the end and then using shift) for it to crash.

Interestingly, clicking on the last line also used the append new text _ character even when not at the end, instead of the | character normally used when inserting between existing text. Also, making selections by double-clicking on other lines showed the selection in the wrong place. Both of those have been fixed in 20w17a.


IMO, deletion of the § character not removing the character after it should be a separate report from clicking being offset a few characters (MC-181539).

Nassim Jahnke

(Unassigned)

Community Consensus

Crash

Minecraft 1.14, Minecraft 1.14.1 Pre-Release 1, Minecraft 1.14.1 Pre-Release 2, Minecraft 1.14.1, Minecraft 1.14.2 Pre-Release 1, ..., 1.14.4 Pre-Release 7, 1.14.4, 1.15.1, 1.15.2, 20w17a

20w17a

Retrieved