Management UI: changing queue type resets most of the declaration form (namely the virtual host selected)

[mgrafl]

Describe the bug

When creating a queue via the RabbitMQ management UI, changing the queue Type unexpectedly resets the Virtual Host to "/".
Since the Type input is below the Virtual Host input, this is not intuitive and often leads to queues being created on the wrong vhost.

Reproduction steps

1. Open the RabbitMQ Management UI.
2. Go to the "Admin" tab, in the "Virtual Hosts" sub-tab, add a new virtual host (e.g., "myhost").
3. Go to "Queues and Streams" tab.
4. Expand the "Add a new queue" section.
5. For Virtual Host input, select the newly created virtual host.
6. For Type input, select any other type.
7. Virtual Host is suddenly reset to "/".

Expected behavior

Virtual Host input should retain selection (i.e., "myvhost") regardless of Type.

Additional context

RabbitMQ version 4.2.1

[lukebakken]

@mgrafl I wish every user provided such a clear issue report. Thank you!

My opinion is that re-ordering input is the best solution here, which is what #15016 does. "Type:" is displayed before "Virtual host:"

The issue is that the code that runs when a queue type is selected forces a re-render of the UI, which results in "Virtual host:" re-setting to whatever the global selection is in the upper-right. The effort and js hackery required to work around this intrinsic UI behavior isn't worth the effort IMHO.

None of the other fields / inputs in "Add a new queue" causes a UI refresh.

[lukebakken]

PS @mgrafl what did you use to capture the screen and create that gif?

[mgrafl]

I used the Windows 11 built-in Snipping Tool. Started the screen recording via Win + Shift + R, trimmed the video and exported it as GIF. Finally, something mundane as this works out-of-the-box.

[michaelklishin]

I primarily use rabbitmqadmin queues declare but even then, I agree that this behavior is annoying.

No objections to #15016 specifically from me either.

[michaelklishin]

I cannot say that #15016 is guaranteed to address this because we assume that the user will fill out the form starting with the topmost dropdown.

But the change was trivial and it is backwards compatible, so let's see if we'd need to mess with the form updating code or this clever form rearrangement would be enough.

Thank you @lukebakken @mgrafl.