mojira.dev
MC-303247

When the player enters a dialog while they are in a GUI, and then said GUI is forcibly closed, the dialog is also forcibly closed

When the player enters a dialog while they are in a GUI, and then said GUI is forcibly closed, the dialog is also forcibly closed.

This behavior has some advantages, namely for the case where it is desired to replace a block or entity’s GUI with a dialog (since the dialog will automatically disappear if the block or entity is destroyed). However, there are surely cases where a datapack developer would like to show the player a dialog and assume that it will remain open until the player either dies, changes dimensions or performs a manual action such as clicking a button on the dialog, pressing Escape or quitting to the title screen. As an example, consider a server event where a dialog is shown to enable players to vote on which minigame they want to play– a player who is shown this dialog at the instant the villager they are trading with is slain by a zombie may never see it and assume that the vote system was simply bugged.

To reproduce

Recreate the setup below, with the trapped chest at the west (-X) end.

[media: 2025-10-16_10.19.19.png]

The first impulse command block (on the right) has the command

dialog show @p {type:"minecraft:multi_action",title:"Some dialog",actions:[{label:":)"}],pause:false}

The second one has the command

setblock ~-4 ~ ~ air

And the chain command block on top of it has the command

setblock ~-4 ~-1 ~ minecraft:trapped_chest[facing=north]

Then open the trapped chest.

Observed result

The shown dialog is closed immediately

Expected result

The shown dialog would remain open

Note

My particular use case is that I want to replace the enchanting table’s GUI with a dialog which allows players to randomly enchant their enchantable gear. I would of course prefer to use a data-driven GUI, but it would take some work for Mojang to implement those. Until they exist, a simpler solution for this sort of functionality would be to allow players to put a boolean argument at the end of their dialog command to specify whether the dialog should be treated as a replacement for the current GUI. When set to true, the existing GUI is closed when the dialog is opened so that the player is not put back into it upon exiting the dialog, but the dialog is still closed if the block is destroyed or the player is moved out of interaction range of it. At present I need to set can_close_with_escape to false, detect when the dialog is closed, and replace the enchanting table with a light block and block display for 2 ticks so that its GUI is forcibly closed- if this issue were fixed (without implementing my suggestion), I would have to manually check whether the block has been destroyed and close the dialog if so, but I would be able to destroy the dialog when the player interacts with the enchantment table rather than when they close the dialog, so the dialog could be made escapable. So ultimately a clean fix may be better for me than the current behavior, but having that extra argument would be really handy.

Attachments

Comments 0

No comments.

clamlol

(Unassigned)

Confirmed

Platform

Normal

Commands, UI

1.21.10, 25w42a

Retrieved