Collapsible categories cause the toolbox to change widths

[alpaslan-exe]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

the selection menu to the left where blocks are chosen from is not uniform in its function. When clicking certain categories of blocks, the current blocks in editor shift slightly, whilst, with bigger tabs, the category opened will simply overlay over the current blocks chosen. There are two solutions that I can see to this problem: either make all menus overlay the code without a shift or simply make all menus regardless of size shift the blocks further to the right. This was observed in an implementation of Blocky and was reported as a bug in Blocky by the developer. Please see google/coding-with-chrome#295.

Reproduction steps

1. Launch an instance of blocky editor with menu's
2. Click on a menu with more blocks
3. watch the current blocks shift
4. click on another menu with smaller/fewer blocks
5. watch the menu not shift.

Stack trace

No response

Screenshots

No response

Browsers

Chrome desktop

[maribethb]

More specific repro steps:

1. Open toolbox demo https://google.github.io/blockly-samples/examples/toolbox-demo/
2. Drag any block onto the workspace
3. Click the "Library" collapsible category
4. Observe how the toolbox gets wider to accommodate the subcategory "Jabberwocky", which causes the main workspace to shift over

[bsampada7]

Hi @maribethb , can I work on this issue?

[BeksOmega]

I think this is WAI. The toolbox defines the edge of the workspace, so we expect things to shift to accommodate it. If we change this it changes the definitions of our absolute top/left, which will probably have downstream impacts to people with custom metrics managers.

Re-marking as triage.

[maribethb]

I think we're going to call this working as intended.

If we changed the behavior, it would be to find out the width of the largest category name (even if it is currently collapsed) and always make the toolbox wide enough to accommodate it. We wouldn't change how the workspace metrics are defined in relation to the toolbox. But it's not clear always having the toolbox wider would actually be a better default state of things. If someone wants that in their application they can implement a custom toolbox.

[alpaslan-exe]

I think it's quite reductive to say that this is working as intended when there's a clear bug in the end product. I understand that resources may be prioritized to something more critical but this is definitely not working as intended. I think others who observe the UI bug would agree with me.

[BeksOmega]

Hello, I think there was a bit of a communication issue here! I agree that the behavior does look buggy, but there's not really a good solution to the problem from a UX / backwards-compatibility perspective :/

(This is a bit of a simplification but please 🐻 with me)

We use the toolbox to define lots of things about the metrics of a workspace. For example, if you have a single block in your workspace, you can't scroll it behind the toolbox:

Screen.recording.2024-06-03.9.04.55.AM.webm

This is defined by a metrics manager, which it is possible for folks to override. Because of that, making it so that the toolbox /doesn't/ define the edge of the workspace (because expanding it doesn't move the edge of the workspace) would have a lot of downstream impacts.

That being said, it may actually be possible for you to do what you want with a custom metrics manager!

[maribethb]

Or instead of defining a custom metrics manager, if your toolbox definition is static, you can just make the width of your toolbox as wide as it will ever need to be for the widest collapsible category, instead of just as wide as it needs to be for the currently open categories. If the width of the toolbox doesn't change then the left edge of the workspace wouldn't change either.

Both of those solutions are possible for an application owner to develop if they want them. And both of them would not be a desirable default state for Blockly to ship with. So that's why we're calling it working as intended from core's perspective - if you don't want it to work this way in your own application then we already provide the APIs needed to customize this.