"Droppable" dropdown menu inputs don't get darkened when menu is open

[towerofnix]

Expected Behavior

The dropdown menu input gets darkened when the menu is open (i.e. when the input is clicked). It's supposed to look basically like this (but of course on an input that accepts blocks):

Actual Behavior

The input isn't darkened. This is how it actually looks:

Steps to Reproduce

Drag out a block with a dropdown menu input that accepts a block (such as "distance to mouse-pointer", "create clone of myself", or "start sound").

Operating System and Browser

Debian (testing), Firefox 60.0b4.

[rachel-fenichel]

Should be related to this code: https://github.com/LLK/scratch-blocks/blob/develop/core/field_dropdown.js#L255

[towerofnix]

Some investigation on this - the issue itself isn't that this.disableColourChange_ is true (it isn't), it's that the code for the branch "if (this.sourceBlock_.isShadow()) {..}" isn't having an effect. Square inputs aren't shadows, and they run the branch below (this.box_.setAttribute(...)), which does work.

If that's right, the code to be fixed might be in core/block_render_svg_vertical.js (updateColour).

Edit: Yup! It looks like shadow blocks are strictly always rendered with the secondary color: https://github.com/LLK/scratch-blocks/blob/fc29f9230a1b58b36db5179a7adfa5662687678a/core/block_render_svg_vertical.js#L523-L529

[towerofnix]

The culprit of this is #962 (I thought it might be #1125 but the issue is still around before that). @rachel-fenichel I'm pinging you since you're the one who wrote that and might have thoughts here.

For what it's worth, reverting #962 fixes this. But I haven't tested custom procedure inputs, which would probably be affected by the revert.

[towerofnix]

Yeah, this does have an affect on custom blocks. Admittedly not the effect I expected, but not really surprising - ordinary:

..and with the revert:

I don't think any other blocks are affected by the revert, but this will need to be figured out.

Actually, I'm wondering why #962 was made in the first place, since I don't think custom procedures were around then, and I can't find anything else that might have affected.

[rachel-fenichel]

I'm surprised that reverting #962 doesn't change all of the other shadow blocks, actually. Does that mean that something else is controlling the colors for all of the blocks that are shadows these days?

The point of #962 was that there are a general rule that we could apply for coloring blocks (shadow blocks are darker) and so we did. That also lets us use the same block in a shadow and outside of it, without explicitly setting the color on each one. Nothing to do with custom procedures.

It sounds like you want another rule to be added on top of that (for all single-field shadow blocks when they're being edited?), or else you want a way to override the effect of that rule sometimes.

#1125 shouldn't matter, since that's specific to custom procedures.

[samelhusseini]

I've fixed this on our side. @rachel-fenichel if you like this fix, I'm happy to port over here.
microsoft/pxt-blockly#128

[rachel-fenichel]

@kchadha thoughts?