Mutator UI dialog on disabled block with a 'input blinking' behavior

[joseluiz98]

Describe the bug

Block's inputs are 'blinking' while opening and closing the mutator UI, for disabled blocks. If the block is disabled, and the user keeps opening and closing the mutator dialog (clicking on the gear located at the block's top left corner), we're able to find the input 'blinking', getting itself visible when the UI dialog tis open, and hidden when its closed.

To Reproduce

Steps to reproduce the behavior:

1. Get a block with a mutator attached to it and a empty input
2. Right click on it and choose 'Disable Block ' observe how you can't see the input among the 'disabled state' of the block with the mutator UI dialog closed
3. Now, open the mutator clicking on the gear.
4. Observe how the input now turns itself 'visible', blinking once on your screen.

Expected behavior

The input can't change its state following the UI its opened and closed, i'm not sure about which of the two states (most or less visible) its the correct one.

Screenshots

Closed UI and you can't see the input

Opened the mutator UI dialog and now the input 'glows' on the screen

Desktop (please complete the following information):

• OS: [e.g. iOS] Ubuntu 20.04.1 LTS
• Browser [e.g. chrome, safari] Chrome
• Version [e.g. 22] 88.0.4324.182 (Versão oficial) 64 bits

Stack Traces

Replace with error stack trace.

Additional context

I'm using Blockly's Zelos Renderer

[alschmiedt]

Thanks for reporting!

I can confirm this issue is happening. I think the correct behavior here is for the inputs to always be visible. That is how it works in the geras renderer and we allow users to connect blocks to inputs when the block is disabled.

[alschmiedt]

Looked into this a bit this release and it looks like this line is causing the problem.

Not sure why yet, but I think it has something to do with the randomIdentifier on the disabled pattern changing when we update the textContent.

[BeksOmega]

I think the issue is that each workspace gets its own set of pattern defs. This includes the main workspace and flyout workspaces. This is a problem because whenever new defs get generated for a specific workspace the global css gets reinjected. So currently the disabledPatternId used in zelo's CSS is being set to the ID of the disabled pattern in the trashcan flyout, which doesn't work (probably a scope thing).

I this could be fixed by either:

1. Not relying on CSS, and instead setting the fill directly in updateDisabled.
2. Making defs/CSS global instead of workspace-specific.